NAT/Firewall Traversal April 2009

NAT revisited – “port-translating NAT”

NAT’s effect on applications NAT affects P2P applications where each peer may need to be contacted. VoIP is one such application: each user needs to have an address for other users to “call” him/her. –E.g. in SIP’s case, the addresses in the INVITE message sent by UA are all private addresses! Cannot be used by target UA to reply. The problem is complicated by different types of NAT STUN is a protocol/algorithm to differentiate different NATs or firewalls

RFC 3489 STUN = Simple Traversal of UDP datagram protocol through NATs Simple protocol that lets application discover if it is behind firewalls and NAT boxes if so, what kind of firewall/NAT boxes And external port/address assigned by the NAT Useful for interactive multimedia application when each peer needs its contact information known, e.g. Skype

NAT and STUN Node with private address X NAT box Stun client Application at address Y port P Stun server request response NAT box has public address Z Maps “X at port R” to “Z at port Q” May do filtering so not all nodes knowing Z/Q can talk to X State: X/R = Z/Q

Types of NATs Full cone NAT – no filtering at NAT Restricted cone NAT – NAT with filtering: only previously contacted node can talk to X Port-restricted NAT – NAT with filtering: only previously contacted port number can be used to talk to X Symmetric NAT – most restrictive filtering: when X talks to different external appls Y/P and Z/Q, they result in different external address/port for X

Symmetric NAT discovery

Full cone NAT discovery

Restricted cone NAT discovery

Port-restricted cone NAT discovery

Firewalls Node with private address X Firewall Stun client Application at address Y port P Stun server request response Some firewall may block all UDP Some firewall may allow UDP response if sent from Y/P where an earlier UDP request was sent to (“symmetric firewall”)

Different cases detectable using STUN Node has public address Node behind firewall that blocks UDP Node behind symmetric firewall Full cone NAT Symmetric NAT Restricted NAT or port-restricted NAT

STUN Request and Response The STUN response from the server may include: MAPPED-ADDRESS- In Binding Responses. It contains the IP address and port of client. CHANGED-ADDRESS- In Binding Responses. It contains the alternate IP address and port of the server. SOURCE-ADDRESS- In Binding Response. It contains the IP address and port of server. The STUN request can contain a flag to request the STUN server to use alternative address and port to send STUN response CHANGE-REQUEST- In Binding Request. It contains flags for the alternate IP address and port of server.

Flow chart for NAT discovering process

How to find STUN servers Application specific way –E.g. Skype probably relies on public Super Nodes to serve as STUN servers –Super Nodes are found in Host Cache, initially populated by the well-known login server Using SRV records in DNS –The application/service provider populates SRV record for STUN servers –This is similar to how SIP proxy servers are found

“Hole Punching” – RFC5128 Alice (with private address) wants to call Bob Bob is also behind NAT box (with private address) Alice talks to public (STUN) server, so server knows Alice’s external address/port Bob also talks to public server, so server knows about Bob too Public server tells Alice about Bob, and Bob about Alice Bob sends packet to Alice (creating a “hole” in his NAT) AliceBob server1 2 34

Direct connection Now when Alice sends a packet back to Bob, Bob’s NAT does not filter it, assuming it is return packet from earlier request Alice’s NAT also allows Bob’s future packets to return This assumes Alice’s NAT will use the same external address/port (for server) to talk to Bob. This does not work if NATs are Symmetric NATs AliceBob server1 2 34

Brute force methods If both NATs are symmetric, may still be able to guess the address/port of the hole, by port scanning! –Such techniques are very ad hoc Last resort: use a relay (all stream data go through a third party) –Performance is worse off –Need someone to be relay

Reference For more detailed description, read an article about NAT in The Internet Protocol Journal, Vol 7, Num 3, September Also at: Read about UDP hole punching from Wikipedia. IETF RFC 5128