I have been using IPSec a lot on OpenBSD and Mac OS X, but switched
almost completely to OpenVPN.
As far as I'm concerned OpenVPN is far less complex, works well with
NAT (off course you can NAT-T with OpenBSD, but Mac OS for example
doesn't support that), the design looks good, is based on OpenSSL and
is (possibly chrooted) user-level in stead of kernel complexity.
Now I might see it wrong, but I'm more pleased with OpenVPN then I've
ever been with IPSec. Maybe you should also try it.
And no, I'm not associated in anyway with the OpenVPN project. I just
like it.
On your question, this is what I have used form my IPSec tunnel's nat:
Internal network 192.168.8.0/24
Remote network 192.168.1.0/24
vpnip="192.168.1.1"
scrub in
nat on enc0 from { gem0, gem0:network } -> $vpnip
Together with:
# cat /etc/hostname.enc0
up
!ipsecadm flow -out -require -proto esp -src 192.168.8.254 -dst
<REMOTE-ENDPOINT> -addr 192.168.8.0/24 192.168.1.0/24
And that worked fine for me. So you'll need to 'manually' add a
Security Association.
Kind regards,
--
Stephan
On 21-dec-2005, at 10:09, Matthew Closson wrote:
Hello,
I'm running into an issue which was brought up on the list before,
the last reference I found was in 2004:
http://archive.openbsd.nu/?ml=openbsd-pf&a=2004-10&m=430206
I have an OpenBSD 3.8 machine.
dc0 is an internal NIC assigned 192.168.20.250
fxp0 is an external NIC assigned a.b.c.d public_IP_address
10.0.20.254 is an inet alias on fxp0
192.168.20.0/24 is my internal network.
192.168.20.0/24
|
|
|
192.168.20.250 - dc0
10.0.20.254 - inet alias on fxp0
a.b.c.d - fxp0 public_IP
|
|
IPSEC Tunnel
|
|
e.f.g.h - public_IP tunnel endpoint
192.168.60.0/24 remote network
According to the parameters of the tunnel setup (of which I cannot
change) the remote IPSEC tunnel endpoint expects traffic from my
network to look like it is coming from 10.0.20.254/32.
This works:
ping -I 10.0.20.254 192.168.20.10
I get responses back from the pings, now I need to nat my internal
network to appear to be coming from 10.0.20.254
So I can do:
nat pass on enc0 from 192.168.20.0/24 to 192.168.60.0/24 ->
10.0.20.254
And what happens is, packets coming in from the 192.168.20.0/24
network hit my internal NIC, are evaluated for IPSEC routing, are
not part of an SPI and are not sent over enc0. This is because
IPSEC routing takes place before pf and nat.
In the message I linked to above, Cedric said that you can get
around this by creating a fake flow into an existing SPI so that
your incoming traffic gets routed into enc0 and then nat'd
appropriately. He said you could run this flow from a cron script,
I suppose that would run every period of time that your SPI times out.
This doesn't seem real solid to me if you need traffic to stay up
over your tunnel. If your script doesn't run at the right time,
your existing connections over the tunnel are going to fall apart.
In another message someone suggested patching isakmpd to modify
this behavior.
My questions are:
Is there a better or newer way of doing NAT before IPSEC routing?
Does anyone have a script for adding fake flows to SPI's periodically?
Does anyone have a source patch for isakmpd that solves this issue?
Any info is much appreciated,
I am subscribed to the list.
Thanks,
-Matt-
