Re: [Openvpn-devel] 2.1 rc20 and multiple interfaces problem

[Davide Brini]

On Saturday 12 December 2009, James Yonan wrote:

> Using nobind on the client for UDP client connections generates a socket
> with a dynamic source port number.  This is key because it means that
> when the client reconnects, it does so with a new source port number,
> and this allows OpenVPN to detect that the initial UDP packet represents
> a new connection, and is not part of the old connection.
> 
> The problem is that when nobind is not used, the source port on the new
> connection is recycled -- it's the same as the old connection.  So when
> OpenVPN sees the connection-initiating packet, after the client switches
> over to the secondary server address, it gets confused because it
> doesn't expect sessions from a given source address to change its
> destination address mid-session.

Quite subtle, but makes sense indeed. 
If I can make a suggestion, I'd add a note in the documentation about this 
particular interaction between the use of "multihome" on the server and not 
using "nobind" on the client (though it should be rare to see clients without 
"nobind", agreed), so other people won't be puzzled as I was when trying to 
debug it.

Thanks again!

-- 
D.

Re: [Openvpn-devel] 2.1 rc20 and multiple interfaces problem

[James Yonan]

Davide Brini wrote:

On Friday 11 December 2009, James Yonan wrote:


Try adding the "nobind" directive to your client config file.  I think
this will solve the problem.


That seems indeed to do it. Thank you very much!

However, never in my life could I have imagined that this was due to a setting 
*on the client*. For single-homed clients, my (possibly wrong) understanding 
was that using or not using "nobind" would essentially be the same. 
Since now I'm curious, could you please kindly provide a bit more insight as 
to *why* using "nobind" on the client fixes it, and how that affects the 
server?


Using nobind on the client for UDP client connections generates a socket 
with a dynamic source port number.  This is key because it means that 
when the client reconnects, it does so with a new source port number, 
and this allows OpenVPN to detect that the initial UDP packet represents 
a new connection, and is not part of the old connection.


The problem is that when nobind is not used, the source port on the new 
connection is recycled -- it's the same as the old connection.  So when 
OpenVPN sees the connection-initiating packet, after the client switches 
over to the secondary server address, it gets confused because it 
doesn't expect sessions from a given source address to change its 
destination address mid-session.


James

Re: [Openvpn-devel] 2.1 rc20 and multiple interfaces problem

[Davide Brini]

On Friday 11 December 2009, James Yonan wrote:

> Try adding the "nobind" directive to your client config file.  I think
> this will solve the problem.

That seems indeed to do it. Thank you very much!

However, never in my life could I have imagined that this was due to a setting 
*on the client*. For single-homed clients, my (possibly wrong) understanding 
was that using or not using "nobind" would essentially be the same. 
Since now I'm curious, could you please kindly provide a bit more insight as 
to *why* using "nobind" on the client fixes it, and how that affects the 
server?

Thank you. 

-- 
D.

Re: [Openvpn-devel] 2.1 rc20 and multiple interfaces problem

[James Yonan]

Davide,

Try adding the "nobind" directive to your client config file.  I think 
this will solve the problem.


James

Davide Brini wrote:

On Thursday 12 November 2009, David Sommerseth wrote:


On 12/11/09 19:33, Olaf Fraczyk wrote:

Hello,

No, I wasn't using --multihome - I didn't know that this option exists
and that is necessary. I haven't found it in man page and in
documentation on the web page. The only place where I found it (after
you let me know about it) was with openvpn --help.

Thank you, I'll try it.
BTW, why is it not by default?

Regards,

Olaf

On Thu, 2009-11-12 at 04:15 -0700, James Yonan wrote:

Are you using the --multihome option?


Sorry to jump in here, but I've run into a weird behavior when using multihome 
in all versions, up to rc15 (I haven't tried later versions, but I guess that 
it would be the same thing since I don't see anything related to this in the 
changelog). I'm using Gentoo on both the client and the server.


In short, it seems that, despite having "multihome" enabled, the server still 
sends replies back to the client out the "wrong" interface, but only under 
certain (not clearly defined) conditions and only after some time(?).


Here is the server config (don't mind IP addresses, this is a lab network):

port 1194
multihome   
proto udp

dev tap0
ca ca.crt
cert server.crt
key server.key
script-security 2
up up.sh
down down.sh
dh dh1024.pem
server-bridge 10.0.1.251 255.255.255.0 10.0.1.10 10.0.1.20
ifconfig-pool-persist ipp.txt
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 6

And here is the client config:

client
remote 1.1.1.1 1194
remote 2.2.2.2 1194
remote-random
proto udp
dev tap0
ca ca.crt
cert client.crt
key client.key
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3

What I've noticed is that the very first connection from a client, regardless 
of the interface it hits, works fine. But for example, if that same client 
disconnects and then reconnects to the other interface (because of the remote-
random option), then the problem happens. However, if another client connects 
second (rather than the first one disconnecting and reconnecting), the second 
client doesn't have problems, regardless of the interface it connects to.
Here is an excerpt of the server log taken during the very first client 
connection:


--
Thu Nov 12 19:58:16 2009 us=7043 192.168.2.2:1194 TLS: Initial packet from 
192.168.2.2:1194 (via 2.2.2.2), sid=68a926bd 92b98d25
Thu Nov 12 19:58:16 2009 us=7235 192.168.2.2:1194 UDPv4 WRITE [26] to 
192.168.2.2:1194 (via 2.2.2.2): P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] 
pid=0 DATA len=0


Thu Nov 12 19:58:16 2009 us=146570 192.168.2.2:1194 Data Channel Encrypt: 
Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 12 19:58:16 2009 us=146664 192.168.2.2:1194 Data Channel Encrypt: 
Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 12 19:58:16 2009 us=146802 192.168.2.2:1194 Data Channel Decrypt: 
Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 12 19:58:16 2009 us=146886 192.168.2.2:1194 Data Channel Decrypt: 
Using 160 bit message hash 'SHA1' for HMAC authentication

...
Thu Nov 12 19:58:16 2009 us=151489 192.168.2.2:1194 Control Channel: TLSv1, 
cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Nov 12 19:58:16 2009 us=151588 192.168.2.2:1194 [Test-Client] Peer 
Connection Initiated with 192.168.2.2:1194 (via 2.2.2.2)
Thu Nov 12 19:58:17 2009 us=181119 Test-Client/192.168.2.2:1194 UDPv4 READ 
[104] from 192.168.2.2:1194 (via 2.2.2.2): P_CONTROL_V1 kid=0 [ ] pid=26 DATA 
len=90
Thu Nov 12 19:58:17 2009 us=181558 Test-Client/192.168.2.2:1194 PUSH: Received 
control message: 'PUSH_REQUEST'
Thu Nov 12 19:58:17 2009 us=181841 Test-Client/192.168.2.2:1194 SENT CONTROL 
[Test-Client]: 'PUSH_REPLY,route-gateway 10.0.1.251,ping 10,ping-restart 
120,ifconfig 10.0.1.10 255.255.255.0' (status=1)

...
Thu Nov 12 19:58:30 2009 us=170924 Test-Client/192.168.2.2:1194 UDPv4 WRITE 
[77] to 192.168.2.2:1194 (via 2.2.2.2): P_DATA_V1 kid=0 DATA len=76
Thu Nov 12 19:58:30 2009 us=172448 Test-Client/192.168.2.2:1194 UDPv4 READ 
[77] from 192.168.2.2:1194 (via 2.2.2.2): P_DATA_V1 kid=0 DATA len=76

Thu Nov 12 19:58:30 2009 us=172747 Test-Client/192.168.2.2:1194 TUN WRITE [42]
---

As you can see, the connection keeps using the 2.2.2.2 IP address. The 
connection works fine indeed. So far so good. But here's what happens if the 
client disconnects and reconnects to the other IP address (excerpts):


---
Thu Nov 12 19:58:47 2009 us=536468 Test-Client/192.168.2.2:1194 TLS: new 
session incoming connection from 192.168.2.2:1194 (via 1.1.1.1)
Thu Nov 12 19:58:47 2009 us=536712 Test-Client/192.168.2.2:1194 UDPv4 WRITE 
[26] to 192.168.2.2:1194 (via 1.1.1.1): P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 
0 ] pid=0 DATA len=0
Thu Nov 12 19:58:47 2009 us=538918 Test-Client/192.168.2.2:1194 UDPv4 READ 
[22] from 192.168.2.2:1194 (via 1.1.1.1): P_ACK_V1 kid=0 [ 0 ]
Thu Nov 12 19:58:47 2009 

Re: [Openvpn-devel] 2.1 rc20 and multiple interfaces problem

[James Yonan]

David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/11/09 19:33, Olaf Fraczyk wrote:

Hello,

No, I wasn't using --multihome - I didn't know that this option exists
and that is necessary. I haven't found it in man page and in
documentation on the web page. The only place where I found it (after
you let me know about it) was with openvpn --help.

Thank you, I'll try it.
BTW, why is it not by default?

Regards,

Olaf
On Thu, 2009-11-12 at 04:15 -0700, James Yonan wrote:

Are you using the --multihome option?


James, this option is not documented in the man pages, AFAICS.  Could
that be the reason the needed use was not discovered?


I've documented --multihome in the man page.  The change has been 
checked into svn and will be in the next release.


James

[Openvpn-devel] 2.1 rc20 and multiple interfaces problem

[Olaf Fraczyk]

Hello,

I have several interfaces, the problem is that if:

I open connection from client to server IP=Y on interface ppp1 then I
get packets back from IP=X on interface ppp0

For connection to IP=X on interface ppp0 I get correctly packets from
IP=X on ppp0.

I have read that in 2.1 it should work, but it doesn't.

The OS is CentOS 5.4.

Best regards,

Olaf
-- 
Olaf Frączyk 
NAVI
http://www.navi.pl
http://www.ntp.navi.pl