How does it work?

[klaymen]

Hi guys,

I just got an NV+ and I'm playing around with the ReadyNAS Remote Addon. Because I'm worried about security, I was looking for more information on how it technically works... is there any information around? I could not really find anything. My main question is whether all data will be routed over a remote server (which would make things slow), or if the central server is only used at the initial stage. If so, how can it work? Is it relying on IGD? Or some other mechanism?

Thanks in advance, Andy

[HERBIEO]

Readynas remote uses leafnetworks adapter which is installed when you install the remote software, if you are wondering how it works read here > http://www.leafnetworks.net/technical_summary.html

[klaymen]

Thanks for the information.. still I don't understand how this should work, the explanation is a bit short. I also found this thread: http://www.readynas.com/forum/viewtopic.php?f=75&t=30019 (a bit old, but same discussion), it does not explain things to me though.

As far as I understand a NAT router does *not* simply allow in any data from an IP that you previously sent traffic to. At least the local port number of the peer must be correct as well - but how can the peers *or* the leaf networks server know this port? The port will be assigned by the NAT router and should be random. Example (sorry, it is very complicated to explain):

notation: <ip1:port1/ip2:port2> is a packet from IP1 to IP2/port2 that uses port1 as source port (each TCP connection is identified by such a quadrupel).

setup is peer1 <-> NAT1 <-> leaf <-> NAT2 <-> peer2

Peer1 contacts the leaf server over NAT and sends a SYN packet <peer1:port1/leafIP:port2>.

NAT1 Router assigns *new* local port port3, so the SYN packet is rewritten to <NAT1:port3/leafIP:port2> - this is what the leaf server sees.
NAT1 also will allow data back from <leafIP:port2> to <NAT1:port3> in.

server replies and peer 1 sees an ACK packet <leafIP/port2:peer1/port1> (NAT translates port number back, peer1 never gets to know the value of port3)

Summary:
- SYN <peer1:port1/leafIP:port2>, rewritten to <NAT1:port3/leafIP:port2>
- ACK <leafIP:port2/NAT1:port3> arrives at NAT1 and NAT1 rewrites it:
- ACK <leafIP:port2/peer1:port1> arrives at peer1 (and peer1 does not know port3)
- NAT1 allows in packets like <leafIP:port2/NAT1:port3>

Same for peer2 (I assume both sides use teh same port2 as leaf sever port here):
- SYN <peer2:port4/leafIP:port2>, rewritten to <NAT2:port5/leafIP:port2>
- ACK <leafIP:port2/NAT2:port5> arrives at NAT2 and NAT2 rewrites it:
- ACK <leafIP:port2/peer2:port4> arrives at peer2 (and peer2 does not know port5)
- NAT2 allows in packets like <leafIP:port2/NAT2:port5>

Now I assume the server could send the information <NAT2/port5> to peer1 and <NAT1/port3> to peer2. But now what?

If peer1 would try to send data to <NAT2:port5>, that would cause NAT1 to set up a *new* relation (nothing was sent to that destination yet), so packets would then look like <NAT1:port6/NAT2:port5> (port6 is randomly chosen by NAT1) - but NAT2 would not let it in because neither source IP nor source port match.

If peer2 could then send data that appeared as <NAT2:port5/NAT1:port6> at NAT1, then NAT1 would let it in. But how could this be done? Nobody knows the value of port6 except the 2 NATs (not even the leaf server knows this value), and in addition, peer2 can't easily tell NAT2 to use port5 as local port number - that value is usually chosen randomly.

Of course it might be possible to guess those ports number if they are chosen sequentially (is this the trick? would not be very reliable), or some of the NAT protococols that NAT routers often implemment (also to allow Skype etc) might be used - there are protocols for port discovery and to open "holes" in the NAT router from a local peer. Hence my initial question.

There is an additional problem with non-matching SEQ/ACK numbers in the TCP connection, but there I imagine NAT routers don't really modify or check those, this is probably something only firewalls with deep inspection do (but I'm not 100% sure there).

Cheers, Andy

[StephenB]

The normal answer for double-NAT topologies is that when peer-to-peer connections fail, the traffic remains routed through the server.

[klaymen]

Hmm I checked it using a sniffer now and it seems it works via UDP. First it seems to try TCP, but that fails, and then it switched to UDP. I can't see any packets going directly to the router, so no NAT traversal protocol seems to be used that's directly supported by the router, and I'm not sure how the peer UDP ports can be guessed by the server. Maybe trial and error?

Anyway, before it builds several connections to peerbroker.netgear.com and other servers in this range, using TCP port 443 and UDP port 443. The content is in clear (though using the SSL port), the password is transmitted as a SHA1 hash, but later on only the timestamp of the login and username is used for authentication.

Is the protocol leafnetworks is using (the command=..., conn_dir=..., conn_try=... etc) documented somewhere?

Thanks, Andy

[StephenB]

There is a brief technology overview here: http://www.leafnetworks.net/technical_summary.html

Normally I would expect to see L2TP, and optionally STUN or TURN for NAT traversal (when UDP is the protocol). Though LEAF may be using something else (possibly proprietary)