nat/firewall traversal

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)

Alice Bob

server12

3 4

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

Alice Bob

server12

3 4

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 2004.

http://www.cisco.com/warp/public/759/ipj_7-3.pdf Also at: http://personal.ie.cuhk.edu.hk/~dmchiu/nat_stun_article.pdf

• Read about UDP hole punching from Wikipedia.• IETF RFC 5128