[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 23:02:46 -0400 (EDT)

Hi,

	The CLIENT has 2 uplinks, not the server (Well, the server does too, but it
uses the same IP for both (dual homed)

	The CLIENT has 2 uplinks, both double NAT'd. (Yuck, but what can I do.). So
The router NATs it and sends it out to the next place, that NATs it again, and off
it goes. So by the time the SERVER gets it, its a public IP. So once it arrives, the
IP is distinct for the path back.

	Previously, before the 2 uplinks, I only had the satellite (The one I'm
trying to get working now) . It was double NAT'd before too. Been working on
a different router for 2 1/2 years. 

	If the other side wasn't getting ANYTHING, I'd have elsewhere to look.
But a tcpdump of port 5002 shows there is a conversation going back and forth on
it.... Hrm..... Lemme check something...

	BINGO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

	Even though the CLIENT is contacting the server properly, the SERVER
is responding back from its BASE IP, not the alias'd IP. 

	So, I have :

fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet A.B.C.128 netmask 0xffffff00 broadcast A.B.C.255
        inet6 fe80::203:47ff:fed5:87cb%fxp0 prefixlen 64 scopeid 0x1 
        inet A.B.C.9 netmask 0xffffffff broadcast A.B.C.9

# tcpdump -s 4096 -n port 5002
tcpdump: listening on fxp0
22:59:41.116227 67.47.145.123.10006 > A.B.C.9.5002: udp 14 (DF)
22:59:41.116615 A.B.C.128.5002 > 67.47.145.123.10006: udp 26


	As soon as I put a "local A.B.C.9" into the server, I get :

Tue Aug  7 23:01:58 2007 22: Peer Connection Initiated with 67.47.145.123:10007
	on the server, and 

Tue Aug  7 23:01:59 2007 Initialization Sequence Completed
	on the client.

	Shouldn't OpenVPN automatically return on the same port it
was contacted on, or when the interface is aliased doesn't it know?


			Tuc
	
> 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.&nbsp; If the router maki=
> ng
> 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.<br>
> <br>
> Tuc at T-B-O-H.NET wrote:
> <blockquote
>  cite=3D"mid:200708072212.l77MCZMg011868@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
> e.com"
>  type=3D"cite">
>   <pre wrap=3D""><!---->	With both client/server fully pathed, I still ge=
> t from the=20
> server :
> 
> Tue Aug  7 18:06:14 2007 10: Local Options hash (VER=3DV3): '8ba3908f'
> Tue Aug  7 18:06:14 2007 11: Expected Remote Options hash (VER=3DV3): '40=
> f30d75'
> 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 init=
> ial packet from 67.47.145.123:10004, sid=3Ddc252510 335afd01
> Tue Aug  7 18:07:05 2007 15: TLS: tls_pre_decrypt: new session incoming c=
> onnection from 67.47.145.123:10004
> Tue Aug  7 18:07:18 2007 16: TLS Error: TLS key negotiation failed to occ=
> ur 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=3DV3): '8ba3908f'
> Tue Aug  7 18:08:18 2007 11: Expected Remote Options hash (VER=3DV3): '40=
> f30d75'
> 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 init=
> ial packet from 67.47.145.123:10004, sid=3De96481f6 1efb7639
> Tue Aug  7 18:09:10 2007 15: TLS: tls_pre_decrypt: new session incoming c=
> onnection from 67.47.145.123:10004
> Tue Aug  7 18:09:23 2007 16: TLS Error: TLS key negotiation failed to occ=
> ur 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 w=
> orking
> perfectly. I changed my setup to replace a consumer router with a Cisco r=
> outer
> 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? </pre>
> </blockquote>
> <br>
> <pre class=3D"moz-signature" cols=3D"72">--=20
> Josh</pre>
> </body>
> </html>

____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users