[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NAT *before* routing decision
Chris Wilson wrote:
Trying to get my head around mixing NAT and IPSEC on OpenBSD; hoping you
folks can tell me whether I'm crazy :-)
I'm doing that, but with a somewhat older version of OpenBSD.
So I guess that makes us both crazy :)
I've got IPSEC ala:
10.1.1.1/32 10.1.1.1 -------- 10.2.2.2 10.2.2.2/32
(ie the encryption domain and the vpn endpoints are the same).
Now I'd like the OpenBSD machine at 10.1.1.1 to be able to be able to give
users on it's local LAN access to 10.2.2.2 through the IPSEC tunnel,
NAT'ing the source address to 10.1.1.1
The problem is that because nat is performed after the routing decision
is made packets are sent out of sk0 rather than enc0. The IPSEC
implementation is presumably deciding that a packet from Local-LAN to
10.2.2.2 doesn't match the IPSEC SA and is therefore routing the packet
normally, not via the tunnel. Only once the nat rule has been applied (on
a non-encrypted interface) does the packet match the IPSEC SA.
Is what I'm trying to do possible?
Your analysis of the problem is 100% correct.
So what you need is to convince the kernel that it should
route the traffic using IPSec (to enc0), and then perform
the NAT on enc0.
I cannot give you the exact command, but basically you've to
add a dummy flow (use ipsecadm, pointing to your existing spi)
that will match your packets before NAT. The flow should look
like: "LAN/24 -> 10.2.2.2". The processing on the kernel will
look like that:
- packet arrives on 10.1.1.1 from LAN.something.
- packet match your dummy flow, so IPSec route it through enc0.
- when hitting enc0, packet is NATTED.
- natted packet is send to 10.1.1.1 using real real flow/spi.
You need to play a little bit to get dummy flow right, but as
I said, It's possible at least with a slightly outdated version
Is there any way to force pf to do source-address-NAT as a packet enters
the system rather than as it leaves?
Not without hacking-up PF.