Difficulties establishing VPN tunnel with IPNAT
quakenet1 at optusnet.com.au
Tue Nov 27 07:07:06 PST 2007
On 27/11/2007, at 5:49 PM, Ted Mittelstaedt wrote:
>> -----Original Message-----
>> From: Jerahmy Pocott [mailto:quakenet1 at optusnet.com.au]
>> Sent: Sunday, November 25, 2007 4:48 AM
>> To: Ted Mittelstaedt
>> Cc: FreeBSD Questions
>> Subject: Re: Difficulties establishing VPN tunnel with IPNAT
>> Perhaps, but I'v heard a lot of good things about IPF and IPNAT,
>> especially since the nat is all in kernel where as natd is
>> userland, so
>> there is a slight performance boost possibly there as well..
> I will address this one point here since it's enough to make
> someone scream, it's such an old chestnut.
> natd is always criticized because going to userland is slow. So,
> people who have slowness problems think that is the issue.
> In reality, the problem is that the DEFAULT setup and man page
> examples for natd use the following ipfw divert rule:
> /sbin/ipfw -f flush
> /sbin/ipfw add divert natd all from any to any via ed0
> /sbin/ipfw add pass all from any to any
> This produces a rule such as the following:
> 00050 divert 8668 ip from any to any via de0
> The problem though, is this is wrong. What it is doing is that
> ALL traffic that comes into and out of the box - no matter what
> the source and destination is - will be passed to the natd translator.
> What you SHOULD be using is a set of commands such:
> ipfw add divert natd ip from any to [outside IP address] in recv
> ipfw add divert natd ip from not [outside IP address] to any out recv
> [inside interface] xmit [outside interface]
That does make a lot of sense!
How ever the 2nd rule is slightly confusing me.. Shouldn't it be
like: divert natd ip from [internal net range] to any out via
More information about the freebsd-questions