On Tue, 4 Jul 2006, Stephen Bosch wrote:
Stephen Bosch wrote:
Hi, all:
I am configuring an IPsec tunnel like so:
local_internal_IP -> alias_IP ->remote_peer_IP -> remote_internal_IP
local host | openBSD | Cisco PIX | remote internal host
alias_IP is a carp alias. It is one end of an IPsec security
association. netstat -rn gives this (altered) output:
Encap:
Source Port Destination Port Proto
SA(Address/Proto/Type/Direction)
remote_internal_subnet/23 0 alias_IP/32 0 0
remote_peer_IP/50/use/in
alias_IP/32 0 remote_internal_subnet/23 0 0
remote_peer_IP/50/require/out
The SA is coming up.
I am natting over the alias_IP with this line:
"nat on $enc_if from $local_internal_IP to any -> $alias_IP"
(to pre-empt misunderstanding, I have also tried
"nat on $ext_if from $local_internal_IP to any -> $alias_IP")
From the OpenBSD box, I can ping remote_internal_IP like so:
"ping -I alias_IP remote_internal_IP"
When pinging from the local host, however, pings time out.
It would appear that there is a problem with natting.
The ping works even with all the NAT lines commented out, so it looks
like the nat isn't doing anything at all...
-Stephen-
I don't think what you want to do is currently possible:
Here is your problem:
Let's say you have these settings
internal_host 10.0.0.5
internal_openbsd_nic 10.0.0.1
external_openbsd_nic AAA.AAA.AAA.AAA
Remote_concentrator BBB.BBB.BBB.BBB
Remote_internal_host 192.168.0.10
and they say they need you to look like you are coming from 192.168.0.5
(it happens frequently because of the other side's policy or poor
planning).
So you think no problem, you configure isakmpd and bring up an SA between
192.168.0.5 <--- IPSEC_SA ---> 192.168.0.10
You setup an IP alias on one of your NIC's and assign it that address,
then you think you can do NAT on your enc0. But you can't. Because here
is what happens:
1. packet comes in from 10.0.0.5 -> 10.0.0.1 destined for 192.168.0.10
2. your box looks at it to see if it matches an existing flow in the
Security Association Database (SADB). It does NOT. You have a flow
between 192.168.0.5 and 192.168.0.10, NOT between 10.0.0.5 and
192.168.0.10. So at this point there is no further route to get to that
destination and the packet is dropped. It never reaches your enc0
interface to actually get NAT'd because it FIRST has to match a flow.
In setting up about 30 ISPEC tunnels on an OpenBSD box in the past 6
months I had this issue come up with about 4 of the remote peers.
Typically it is one of two problems.
1. They have a made a policy level decision somewhere and say they will
only route traffic to public IP's or they want to assign you a public IP
from their IP space. Typically this is because they don't want to deal
with the issue of multiple remote networks sharing the same private IP
space.
2. Your IP space conflicts with another existing IP space they are routing
to across another tunnel so they need you to NAT and make it look like you
are coming from somewhere else.
So here is what you can do:
1. Place another box in front of your box doing IPSEC and NAT the traffic
before it gets there based on its destination. I got my setup working
fine this way. Cheap boxes are easy to come by for simply doing NAT.
2. Submit a patch which I'm sure a lot of people would be interested in
that alllows NAT to take place before SADB flow matching, perhaps a
sysctl would be nice.
A lot of VPN adminsitrators seem to think that you should have no problem
NAT'ing this way because many of the current popular VPN concentrators
allow you to do this all on one box.
If you want to test any ideas or setup's privately email me off the list
and I'd be happy to help. Good luck!
man 4 ipsec
NAT can also be applied to enc# interfaces, but special care should be
taken because of the interactions between NAT and the IPsec flow
match-
ing, especially on the packet output path. Inside the TCP/IP stack,
packets go through the following stages:
UL/R -> [X] -> PF/NAT(enc0) -> IPsec -> PF/NAT(IF) -> IF
UL/R <-------- PF/NAT(enc0) <- IPsec <- PF/NAT(IF) <- IF
With IF being the real interface and UL/R the Upper Layer or Routing
code. The [X] stage on the output path represents the point where
the
packet is matched against the IPsec flow database (SPD) to determine
if
and how the packet has to be IPsec-processed. If, at this point, it
is
determined that the packet should be IPsec-processed, it is processed
by
the PF/NAT code. Unless PF drops the packet, it will then be
IPsec-pro-
cessed, even if the packet has been modified by NAT.
-Matt-
