to your isakmpd.conf. Something like the following. Your NAT
then takes
care of the rest.
[VPN-1]
Phase= 2
ISAKMP-peer= remote
Configuration= Default-quick-mode
Local-ID= ip-10.0.20.254
Remote-ID= network-192.168.60.0/255.255.255.0
[VPN-2]
Phase= 2
ISAKMP-peer= remote
Configuration= Default-quick-mode
Local-ID= network-192.168.20.0/255.255.255.0
Remote-ID= network-192.168.60.0/255.255.255.0
[ip-10.0.20.254]
ID-type= IPV4_ADDR
Address= 10.0.20.254
[network-192.168.20.0/255.255.255.0]
ID-type= IPV4_ADDR_SUBNET
Network= 192.168.20.0
Netmask= 255.255.255.0
[network-192.168.60.0/255.255.255.0]
ID-type= IPV4_ADDR_SUBNET
Network= 192.168.60.0
Netmask= 255.255.255.0
Nick
On Wed, 2005-12-21 at 04:09 -0500, 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
