tinc devel - May 2009 - BindToAddress: TCP connections originate from random source address.

Hi,

I've stumbled upon a problem which I can't solve easily with the
available options in tinc - at least as far as I see. If enlightenment
is all I need, I'll happily accept pointers ;)

I try to establish a connection between two hosts. Each host has
multiple addresses assigned to it's internet interface. A stripped down
list would be:

  Host 1:
    2001:780:0:1e::1
    2001:780:0:1e::60

  Host 2:
    2001:780:106::1
    2001:780:106::f1

With the `BindToAddress' I have bound the daemon(s) to the addresses
2001:780:0:1e::1 and 2001:780:106::1. `netstat(8)' confirms this:

  tcp6 0 0 2001:780:0:1e::1:655 :::* LISTEN 5707/tincd          
  udp6 0 0 2001:780:0:1e::1:655 :::*        5707/tincd

The problem is that `BindToAddress' is only used for *listening* TCP
sockets, not for sending TCP sockets. This is a packet sent by tincd
while trying to establish a connection, captured with tcpdump:

  12:07:19.203429 IP6 2001:780:0:1e::60.42881 > 2001:780:106::1.655: S
2460575975:2460575975(0) win 5760 <mss 1440,sackOK,timestamp 1195871553
0,nop,wscale 7>

As you can see, the second address on the interface is used to establish
the TCP connection in this case. On the other hand, the UDP sockets are
bound and used for both, sending and receiving. When the connection is
established, payload shows up like this:

  12:11:17.930350 IP6 2001:780:0:1e::1.655 > 2001:780:106::1.655: UDP, length
108

This time the source address is the expected address, but the other
instance has already learned another IP-address from the TCP connection.
The function `handle_incoming_vpn_data' then fails to look up the host
entry belonging to this IP address and I get the error printed in
line?559:

  Received UDP packet from unknown source 2001:780:0:1e::1

I propose to check the `BindToAddress' configuration in
`do_outgoing_connection' and, if set, bind TCP sockets to that address,
too.

Are there any comments, suggestions, or objections? Otherwise I'd write
a quick patch..

Regards,
-octo

P. S.: Of course I know how to influence the OS and make it pick some
       specific address, and I know about NAT and the like, too. I don't
       think these are ?solutions? to this problem.
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20090526/d941a750/attachment.pgp

On Tue, May 26, 2009 at 06:06:37PM +0200, Florian Forster wrote:
> I've stumbled upon a problem which I can't solve easily with the
> available options in tinc - at least as far as I see. If enlightenment
> is all I need, I'll happily accept pointers ;)
[...]
> The problem is that `BindToAddress' is only used for *listening* TCP
> sockets, not for sending TCP sockets.
[...]
> On the other hand, the UDP sockets are
> bound and used for both, sending and receiving.
[...]
> The function `handle_incoming_vpn_data' then fails to look up the host
> entry belonging to this IP address and I get the error printed in
> line?559:
> 
>   Received UDP packet from unknown source 2001:780:0:1e::1
> 
> I propose to check the `BindToAddress' configuration in
> `do_outgoing_connection' and, if set, bind TCP sockets to that address,
> too.
Yes, that is a simple solution that should work. The same change should
probably also be made for BindToInterface then.
> Are there any comments, suggestions, or objections? Otherwise I'd write
> a quick patch..
A patch would be welcome! But I still wonder about the configure.in patch you
sent?

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url :
http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20090526/dc3a4c73/attachment.pgp