Nat / Direct Connection Confusion!

[overand]

OK folks - "seasoned network administrator" here.

 

I've been hoping to use BTSync to share some business-related files & directories from my employer's systems, to let their clients more easily access some data, etc.

 

But I've run into an 'Unexpected behavior!'

 

I set up the 'server' - Windows 2008 R2 with BTSync, and share the folder.  I've also set a custom 'listen port' and performed a MANUAL NAT / port forward.

 

When the client (who is behind NAT and is *not* supporting uPNP) connects, they get a low, low speed of around 50kilobytes/second, even though the client's download pipe is many, many times that, and the server's upload pipe is many times that as well.

 

When reviewing the open connections on each end, I could see that the 'client' was in fact NOT connecting directly to the 'server.'

 

Is there a reason that the 'relay' servers were being used, even though there was the ability for at least a one-way direct connection?

 

(Yes, I've tested the direct connection, by telnetting to the remote system on the custom port, and I was able to establish a connection).

 

The configuration is fairly normal.  Both systems are behind NAT firewalls.  The "server" has the custom BTSync port forwarded to it.

 

The expected behavior - direct connection from 'client' to 'server' did not happen.  Why?  I'm confused.

 

Also, in the logs, I saw the following unexpected entries.  Note that port "34780" is *not* the port I used - I in fact specified port 61223 - the 'lan port' it's trying to connect to is the right one, but the port it's trying to connect on the actual WAN interface is very wrong!

[2014-02-13 12:59:01.296] ping xxWAN.IPxx.253.205:34780 directly[2014-02-13 12:59:01.296] ping yyLAN.IPyy.63.13:61223 peer local address[2014-02-13 12:59:02.296] Sending broadcast ping for share 5678obfuscatedshare500[2014-02-13 12:59:02.296] Sending broadcast ping for share 0123ObfucsatedShare012300071[2014-02-13 12:59:02.296] Send ping to peer (01234567obfuscatedpeer000C99) for share 0123ObfucsatedShare012300071:[2014-02-13 12:59:02.296] ping xxWAN.IPxx.253.205:34780 directly[2014-02-13 12:59:02.296] ping yyLAN.IPyy.63.13:61223 peer local address[2014-02-13 12:59:03.296] Sending broadcast ping for share 5678obfuscatedshare500[2014-02-13 12:59:03.296] Sending broadcast ping for share 0123ObfucsatedShare012300071[2014-02-13 12:59:03.296] Send ping to peer (01234567obfuscatedpeer000C99) for share 0123ObfucsatedShare012300071:[2014-02-13 12:59:03.296] ping xxWAN.IPxx.253.205:34780 directly[2014-02-13 12:59:03.296] ping yyLAN.IPyy.63.13:61223 peer local address[2014-02-13 12:59:04.297] Sending broadcast ping for share 5678obfuscatedshare500[2014-02-13 12:59:04.297] Sending broadcast ping for share 0123ObfucsatedShare012300071[2014-02-13 12:59:04.297] Send ping to peer (01234567obfuscatedpeer000C99) for share 0123ObfucsatedShare012300071:[2014-02-13 12:59:04.297] ping xxWAN.IPxx.253.205:34780 directly[2014-02-13 12:59:04.297] ping xxWAN.IPxx.253.205:34780 via relay[2014-02-13 12:59:04.297] ping yyLAN.IPyy.63.13:61223 peer local address

[overand]

New thoughts!

 

I was reading a thread: http://forum.bittorrent.com/topic/19214-trouble-with-rotuer/?p=50004

 

This seems to indicate that if your firewall / router 'renumbers' your outgoing connections (i.e. source port) that things will 'break' and you'll end up needing to connect through relays.

 

IS THIS MY ISSUE?  It may be!  I can try disabling the renumbering via my Firewall (pfSense 2.x on both ends, in fact) - but this is Kinda A Problem.

 

Lots of business firewalls do this for security, and no protocols that I've seen from the past 10 years have this sort of 'it doesn't work with renumbering' issue!

 

SIP - sure, but SIP is a train wreck.  I do think some 'paranoid' configurations of OpenVPN may have similar behavior, but seriously folks!  This is not a sane way to handle networking in the year 2014 - you can't count on the outbound port of a client being a certain number!  This is also fundamentally incompatible with having multiple clients behind NAT.

 

Please get rid if this limitation, if that is in fact a current limitation.