On 6/13/06, Stuart Henderson <[EMAIL PROTECTED]> wrote:
(warning, a bit long and might not be of very general interest,
but some of the points probably need getting down somewhere...)

executive summary: passing some protocols through NAT can be pretty hairy.

Of course this is quite like active-ftp, in that local IP addresses
and ports for some remote machine to connect to are carried in the
packets themselves (not the headers).

- to get this particular packet sent so that media is directed
correctly, the NAT would have to rewrite:

Contact: <sip:[EMAIL PROTECTED]:2051;line=aurpydus>;flow-id=1
o=root 1540178600 1540178600 IN IP4 10.0.0.1
c=IN IP4 10.0.0.1
m=audio 64376 RTP/AVP 0 8 9 2 3 18 4 101

10.0.0.1 would be replaced with the NAT routers address; say 81.168.66.254
64376 would be replaced with an unused port number on the NAT router; say
for this example 50172
>
If you're following this, you'll notice that some host sending
an unauthenticated UDP packet can ask the NAT to open a UDP port
from the outside world to any host behind the same NAT...
So, I think this definitely needs to be handled outside of PF,
and accompanied by a reasonably large warning (-:

((Please don't take too much offense to this if it's a really obvious thing))

What is the prefered method for NAT-traversal these days? The options
I know are:
UPnP
a proxy
having the in-kernel NAT code do the work itself
designing protocols to assume NATs and get around them.

It seems to me like it would be helpful if PF provided some sort of
hooks that let you write plugins that understand a particular protocol
and are able to change the neccessary parts at will. Is this
completely bonkers and/or has it been tried and/or is it good?

-Nick

Reply via email to