Ralph Johns

 
New email link
Hi,

I plan to add and Email link butin the mean time.

Use this ralphjohns@lineone.net


Ralph
- posted by Ralph Johns @ 8:49 pm 0 comments

 
Interesting email
Hi All,

I have received this email which points out the differences between Port Forwarding and NAT

Hello Ralph

You have kindly responded to my post about lack of repeatability when using iChatAV for video chat through NAT. Indeed I see that you are very responsive to many queries and others often refer to your helpful Web site.

Offline, I have a comment on the reference you have in your pages to NAT and port forwarding - saying that effectively they are the same thing. I think that it may not help some people to see it this way.

For most situations when connecting from a private network to the Internet via a NAT device the concern is for outgoing or dynamic NAT. Traffic initiated from the inside (private) network has the source address translated to (usually) the public address of the outside interface of the NAT device. In many cases, the source port is translated as well. This is so that reply traffic carries enough information to allow the destination address to be translated to the correct inside address (and port). Replies will come back to the new port which the NAT device uses to look up from its dynamic tables where it should send the reply packets back to.

So reply traffic is allowed in automatically - provided the dynamic NAT tables have not timed out.

What Apple are trying to do is to have one end originate traffic from their iChat AV so that the other end sees it as reply traffic to its own outgoing packets. It is a trick that depends on the NAT device making certain "consistent" choices in how to do the port mapping. This presumably is what routers compatible with iChatAV do - including the Airport Extreme. The trick depends on their being a third-party mediator site and is similar to STUN - Apple say they would have used STUN if they had known about it at the time.
See for example http://www.voip-info.org/wiki-STUN and http://www.newport-networks.com/whitepapers/fwnatwpes3.html

See http://midcom-p2p.sourceforge.net/ for a related test tool. This is not perfect for iChatAV troubleshooting as it reports "consistent" for my Cisco router and for my son's Vigor router (once he had upgraded the firmware) but we could still not establish a video chat.

Port forwarding, on the other hand, sets up a static mapping for traffic originating from the outside to a particular inside address (and possibly port). It is provided for cases where there is a server such as a Web server on the private network. Its use is suggested by Apple for NAT devices that do not do outgoing (dynamic) NAT in the way needed for its trick to work. It is not the best choice to make from the security point of view because of the fact that it is a static (fixed, permanent) mapping allowing outside traffic to reach the inside irrespective of outgoing traffic.

Our problem comes of course because NAT (static and dynamic) was designed for client-server applications and not peer-to-peer applications such as direct video chat.

Just to clarify again the reason for my post, having obtained an Airport Extreme because it is a device on the list of NAT devices that work (ie do NAT in the way Apple needs) I was able to establish a video chat once but not a second time. I have not yet been able to try again after a long delay (to allow any NAT timers to time out) in case that was causing the problem.

Many regards

I wonder if any would find these distinctions helpful.

Comments welcome.

Ralph
- posted by Ralph Johns @ 3:32 pm 2 comments

 
Iteresting email
HI All,

I received this email which questions the info on this site regarding the differences between NAT and Port Forwarding.

Hello Ralph

You have kindly responded to my post about lack of repeatability when using iChatAV for video chat through NAT. Indeed I see that you are very responsive to many queries and others often refer to your helpful Web site.

Offline, I have a comment on the reference you have in your pages to NAT and port forwarding - saying that effectively they are the same thing. I think that it may not help some people to see it this way.

For most situations when connecting from a private network to the Internet via a NAT device the concern is for outgoing or dynamic NAT. Traffic initiated from the inside (private) network has the source address translated to (usually) the public address of the outside interface of the NAT device. In many cases, the source port is translated as well. This is so that reply traffic carries enough information to allow the destination address to be translated to the correct inside address (and port). Replies will come back to the new port which the NAT device uses to look up from its dynamic tables where it should send the reply packets back to.

So reply traffic is allowed in automatically - provided the dynamic NAT tables have not timed out.

What Apple are trying to do is to have one end originate traffic from their iChat AV so that the other end sees it as reply traffic to its own outgoing packets. It is a trick that depends on the NAT device making certain "consistent" choices in how to do the port mapping. This presumably is what routers compatible with iChatAV do - including the Airport Extreme. The trick depends on their being a third-party mediator site and is similar to STUN - Apple say they would have used STUN if they had known about it at the time.
See for example http://www.voip-info.org/wiki-STUN and http://www.newport-networks.com/whitepapers/fwnatwpes3.html

See http://midcom-p2p.sourceforge.net/ for a related test tool. This is not perfect for iChatAV troubleshooting as it reports "consistent" for my Cisco router and for my son's Vigor router (once he had upgraded the firmware) but we could still not establish a video chat.

Port forwarding, on the other hand, sets up a static mapping for traffic originating from the outside to a particular inside address (and possibly port). It is provided for cases where there is a server such as a Web server on the private network. Its use is suggested by Apple for NAT devices that do not do outgoing (dynamic) NAT in the way needed for its trick to work. It is not the best choice to make from the security point of view because of the fact that it is a static (fixed, permanent) mapping allowing outside traffic to reach the inside irrespective of outgoing traffic.

Our problem comes of course because NAT (static and dynamic) was designed for client-server applications and not peer-to-peer applications such as direct video chat.

Just to clarify again the reason for my post, having obtained an Airport Extreme because it is a device on the list of NAT devices that work (ie do NAT in the way Apple needs) I was able to establish a video chat once but not a second time. I have not yet been able to try again after a long delay (to allow any NAT timers to time out) in case that was causing the problem.

Many regards

I am not sure that this would be helpful to many of the people visiting this site.

Comments welcome

Ralph
- posted by Ralph Johns @ 3:24 pm 0 comments