[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] 2nd instance issues


  • Subject: Re: [Openvpn-users] 2nd instance issues
  • From: "Tuc at T-B-O-H.NET" <ml@xxxxxxxxxxx>
  • Date: Tue, 7 Aug 2007 18:12:35 -0400 (EDT)

> Tuc at T-B-O-H.NET wrote:
> > I tried to start a 2nd OpenVPN instance on my server, and a 2nd
> > OpenVPN instance on my client. They are both FreeBSD 5. I copied my ent=
> ire
> > directory over from "openvpn" to "openvpn2". On the client, I changed t=
> he
> > IP I wanted the client to contact the server on. (I needed to do this s=
> ince
> > the remote site would route the traffic to that IP out a different tran=
> sit
> > provider). On both of them I changed the IP set (10.2.0.X to 10.3.0.X) =
> and
> > the ports (From 5001 to 5002). I started them up, but they don't seem t=
> o
> > sync. If I change the IP the client tries to contact the server on back=
> 
> > to the base one, works perfectly.
> >
> > 	Is there something about the certificate and the forward/reverse
> > DNS?
> >
> > 	When it ISNT working, I get :
> >
> > Sun Aug  5 23:30:36 2007 24: TLS: tls_pre_decrypt: new session incoming=
>  connection from 67.47.145.123:10169
> >
> > 	on the server, and=20
> >
> > Sun Aug  5 23:30:36 2007 Re-using SSL/TLS context
> > Sun Aug  5 23:30:36 2007 LZO compression initialized
> > Sun Aug  5 23:30:36 2007 Control Channel MTU parms [ L:1300 D:138 EF:38=
>  EB:0 ET:0 EL:0 ]
> > Sun Aug  5 23:30:36 2007 Preserving previous TUN/TAP instance: tun1
> > Sun Aug  5 23:30:36 2007 Data Channel MTU parms [ L:1300 D:1300 EF:42 E=
> B:135 ET:0 EL:0 AF:3/1 ]
> > Sun Aug  5 23:30:36 2007 Local Options hash (VER=3DV4): '8c473bbe'
> > Sun Aug  5 23:30:36 2007 Expected Remote Options hash (VER=3DV4): '4e31=
> 2712'
> > Sun Aug  5 23:30:36 2007 UDPv4 link local (bound): [undef]:5002
> > Sun Aug  5 23:30:36 2007 UDPv4 link remote: A.B.C.D:5002
> >
> > 	on the client
> 
> [cut]
> 
> > I don't have a local directive. I thought that it=20
> > would bind to "*" and the fact that I changed the ports would keep them=
> =20
> > away from each other.=20
> 
> As long as each server runs on a unique port they can listen on the
> global address to accept connections from anywhere, so this is fine.
> 
> When you copy the directory, have you updated any paths inside the
> config file of the new setup?  Other than a shared file between the two
> (such as the ifconfig-pool-persist option) the 2 instances should be
> completely separate.  Also verify that each instance is using a separate
> adapter on the server and client (if the client is dynamically bringing
> up the tun adapter it should handle this automatically.)  If both those
> ideas don't help, you could try to turn off the persistent-tun setting;
> I'm noticing that the client is re-using the previous tun instance.=20
> While I don't suspect this is a problem, it's one more thing you can try.=
> 
	With both client/server fully pathed, I still get from the 
server :

Tue Aug  7 18:06:14 2007 10: Local Options hash (VER=V3): '8ba3908f'
Tue Aug  7 18:06:14 2007 11: Expected Remote Options hash (VER=V3): '40f30d75'
Tue Aug  7 18:06:14 2007 12: UDPv4 link local (bound): [undef]:5002
Tue Aug  7 18:06:14 2007 13: UDPv4 link remote: [undef]
Tue Aug  7 18:06:18 2007 14: TLS: tls_pre_decrypt: first response to initial packet from 67.47.145.123:10004, sid=dc252510 335afd01
Tue Aug  7 18:07:05 2007 15: TLS: tls_pre_decrypt: new session incoming connection from 67.47.145.123:10004
Tue Aug  7 18:07:18 2007 16: TLS Error: TLS key negotiation failed to occur within 60 seconds
Tue Aug  7 18:07:18 2007 17: TLS Error: TLS handshake failed

	and the client is hitting the inactivity timeout...

	If I take the persistent-tun out of both configs , the client
is still using the same tun (1) and the server is :

Tue Aug  7 18:08:18 2007 10: Local Options hash (VER=V3): '8ba3908f'
Tue Aug  7 18:08:18 2007 11: Expected Remote Options hash (VER=V3): '40f30d75'
Tue Aug  7 18:08:18 2007 12: UDPv4 link local (bound): [undef]:5002
Tue Aug  7 18:08:18 2007 13: UDPv4 link remote: [undef]
Tue Aug  7 18:08:23 2007 14: TLS: tls_pre_decrypt: first response to initial packet from 67.47.145.123:10004, sid=e96481f6 1efb7639
Tue Aug  7 18:09:10 2007 15: TLS: tls_pre_decrypt: new session incoming connection from 67.47.145.123:10004
Tue Aug  7 18:09:23 2007 16: TLS Error: TLS key negotiation failed to occur within 60 seconds
Tue Aug  7 18:09:23 2007 17: TLS Error: TLS handshake failed


	The difference between the 2 IPs, is that they ARE both on the same
machine, except on the remote end the IP that works is getting routed via
broadband wireless, and the IP that DOESN'T work is going over satellite. I
originally set this system up on Satellite 2 1/2 years ago and its been working
perfectly. I changed my setup to replace a consumer router with a Cisco router
that decides which is the best path. But, hardcoded, is if its 128 to use Wireless
and 9 to use Satellite. Could something with the Cisco be screwing things up. Is
there a higher debug I should use on one/other end to tell? 
______________________
OpenVPN mailing lists
https://lists.sourceforge.net/lists/listinfo/openvpn-users