[Q] Naive solution to FreeBSD NAT+IPSEC problem?
Mewtwo
IPSec are theoretically supposed not to work
together. But now I have to set to set up some
IPSec tunnels for a VPN. I want to keep my NAT and
have IPSec too.
I cannot see the difficulty with IPSec and NAT on
FreeBSD with IPFW. Is it not sufficient to put the
firewall rules for IPSec traffic BEFORE the DIVERT
rule to prevent IPSec traffic from being passed
through NAT? Or is this idea just too naive? If
it does work can anyone give an example setup?
It seems from reading FreeBSD mailing lists and news-
groups that there is a lack of definitve documentation
on IPSec administration on FreeBSD. Worse there seems
to be erroneous or at least conflicting advice.
Specifically with respect to use of GIF interfaces.
Is there a good "how-to" for setting up an IP-Sec
tunnel between two networks?
Thank you.
Nick Hilliard
> I cannot see the difficulty with IPSec and NAT on
> FreeBSD with IPFW.
IPsec/AH and NAT are fundamentally incompatible with each other, and it's
nothing to do with FreeBSD.
The problem is that NAT modifies the headers of IP packets. This screws up the
AH mechanism because it changes the original AH checksum of the IP header.
There's no way around the problem as far as I know.
Nick
Bruce Gilmore
implemented by vendors such as Cisco and Checkpoint that will wrap the
entire IPSEC\AH packet in a UDP datagram (port 500) to ship across the
unsecured network. This solution does work with NAT but I think
interoperability between vendors for this alternative is still forming up.
"Nick Hilliard" <nick@foobar#delete2email#.org> wrote in message
news:Ej819.5358$zX3....@news.indigo.ie...
Nick Hilliard
> There is a proposed standard (could be a real standard by now) that is being
> implemented by vendors such as Cisco and Checkpoint that will wrap the
> entire IPSEC\AH packet in a UDP datagram (port 500) to ship across the
> unsecured network. This solution does work with NAT but I think
> interoperability between vendors for this alternative is still forming up.
This is very similar to VPN'ing the whole system, which you can do easily with
ipsec between the two nat devices + ip tunnel over ipsec + clever routing. Not
the most efficient, but NAT is notorious for forcing such ugly hacks.
Nick
Michael Gschwandtner
Hi,
we got the same Problem in OpenBSD
as far as i know the problem relies in the ip_output functio
as there are checked the SA's first and then the Packets
are NATed.
And the real thing i don't understand is that the IPSEC code
in BSD decides first if there is a SA (with the unNATed address)
if no SA is found it goes the Normal way through the PF/NAT
BUT if there is a SA --> IPSEC is needed there is a extra PF/NAT code
only for IPSEC because the IPSEC must know the real address before
encapsulation. I think that choosing a SA based on the unNATed adresse
doesn't make much sense.
Thats why we tried some trick wiht the IPSEC code in ip_output
we moved the PF/NAT code inside the IPSEC block up before IPSEC
decides what SA to choose.
And it works partially. The unencrypted IP traffic seems to be working
normal and the Encrypted Traffic works too, BUT the NAT that changes
the addresses back to internal Numbers doesn't work.
We're trying to fix it, and then we'll make a patch availabe
So if you're interested, you can write to me. Greetings Michael Gschwandtner