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
Is 192.168.8.254 is the IP address of your internal NIC?
Once this has been done, and a fake phase2 entry has been made for the
internal network in the isakmpd.conf file, what else needs to be done.
I tried this and added the flow and phase2 connection (on my end only) and
when I try to access hosts across the tunnel from my internal LAN and run
tcpdump -i enc0 I still see no traffic coming across.
Any ideas of what I could be missing? I did
ipsecadm flow -out -require -proto esp -src 192.168.20.250 -dst a.b.c.d
-addr 192.168.20.0/24 192.168.60.0/24
Thanks,
-Matt-
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-
