NAT/Firewall Traversal
description
Transcript of 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