[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: Josh Cepek <josh.cepek@xxxxxxx>
  • Date: Tue, 07 Aug 2007 21:17:07 -0500
  • Openpgp: id=2E5A5127
  • Z-usanet-msgid: XID395LHHcRT0252X39

Since you have 2 uplinks on the OpenVPN server, you need to insure that a connection coming in on a particular IP goes out that same IP, otherwise the client will discard the responses.  If the router making the decision doesn't keep the outbound reply packets from each OpenVPN connection with the same IP that it arrived on it will lead to the behavior you noticed.

Tuc at T-B-O-H.NET wrote:
	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? 

-- 
Josh

Attachment: signature.asc
Description: OpenPGP digital signature