NAT/Firewall Traversal

19
NAT/Firewall Traversal April 2009

description

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. - PowerPoint PPT Presentation

Transcript of NAT/Firewall Traversal

Page 1: NAT/Firewall Traversal

NAT/Firewall Traversal

April 2009

Page 2: NAT/Firewall Traversal

NAT revisited – “port-translating NAT”

Page 3: NAT/Firewall Traversal

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

Page 4: NAT/Firewall Traversal

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

Page 5: NAT/Firewall Traversal

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

Page 6: NAT/Firewall Traversal

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

Page 7: NAT/Firewall Traversal

Symmetric NAT discovery

Page 8: NAT/Firewall Traversal

Full cone NAT discovery

Page 9: NAT/Firewall Traversal

Restricted cone NAT discovery

Page 10: NAT/Firewall Traversal

Port-restricted cone NAT discovery

Page 11: NAT/Firewall Traversal

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”)

Page 12: NAT/Firewall Traversal

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

Page 13: NAT/Firewall Traversal

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.

Page 14: NAT/Firewall Traversal

Flow chart for NAT discovering process

Page 15: NAT/Firewall Traversal

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

Page 16: NAT/Firewall Traversal

“ 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

Page 17: NAT/Firewall Traversal

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

Page 18: NAT/Firewall Traversal

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

Page 19: NAT/Firewall Traversal

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