Using PF to NAT IPSec connections when network segments overlap (redux)
A while back I was wondering if there was a good way to deal with overlapping network addresses in OpenBSD when setting up site-to-site VPNs. At the time the best solution I could find was just to use relayd (which iirc is now called something else), which works but isn't pretty. I've since found a much better solution, and I want to write it down here so that the next guy doesn't have to spend a day tearing his hair out. First: if you're using a recent version of OpenBSD, and the other side is as well, you may as well try http://www.undeadly.org/cgi?action=articlesid=20090127205841 I haven't, but it looks like a neat solution. In my case, the opposite end of the link is using a Juniper NetScreen, and my firewall is OpenBSD 4.3. I mostly followed the guide here: http://fixunix.com/bsd/87865-nat-ipsec-openbsd-pf-isakmpd.html, which works generally but is wrong in a few particulars. In my case, my company bought another company and we needed to merge networks. Unfortunately, the remote company used 192.168.10.0/24, which was the network on our end that we needed to share. What we did was, the remote end picked an unused network (192.168.14.0/24) and I picked another unused network (192.168.15.0/24). We then set up ipsec to set up the flows: ipsec.conf: ike active esp from 192.168.15.0/24 to 192.168.14.0/24 \ local a.a.a.a peer b.b.b.b \ main auth hmac-sha1 enc 3des group modp1024 \ quick auth hmac-sha1 enc 3des group none \ psk keykeykey (can I just say, by the way, how awesome ipsec.conf is? because it is) Now, as in the guide, we're going to route through lo1 and perform our natting on that interface. However, we do *not* want to assign any IP from the 192.168.15.0/24 network to lo1. This is because we want packets coming in from the enc0 interface to get routed back out of the OpenBSD box, which will not happen if OpenBSD thinks it's the destination for that packet. We do this by assigning lo1 an IP that is completely unrelated to anything else we're doing. Fortunately rfc1918 is generous. I took 192.168.99.1 because I didn't really expect this to work when I tried it. It would be trivial to move out of 192.168/16 altogether, I suppose, but it's even more trivial to leave it where it is: # ifconfig lo1 create # ifconfig lo1 inet 192.168.99.1/32 # route add 192.168.14.0/24 192.168.99.1 # route add 192.168.15.0/24 192.168.99.1 The first route sends packets headed for the IPSec link over lo1, where they will have their source address rewritten. The second rule forces packets over lo1 again, where the proper address is restored. Finally, add the binat rule in pf.conf, and do your firewalling. If you're having trouble, see whether you have `set skip on lo0` or just `lo`. You want the former. I pass all traffic to my NAT address and apply the firewall rules after the NAT when they are checked leaving the lo1 interface: pf.conf: binat on lo1 inet from 192.168.10.0/24 to 192.168.14.0/24 - 192.168.15.0/24 pass on lo1 from any to 192.168.15.0/24 pass on lo1 proto tcp from any to 192.168.10.37 port 80 If everything's working, you should be able to follow packets from the internal interface (bge0, in my case) over lo1, into enc0, and out the external (bge1). Let me know if you find any errors. I'm not on the list, so please cc me.
Re: Using PF to NAT internal addresses over an IPSec link
Well, I've got it. It turns out it's kind of easy, although not as pretty as it could be. Basically, you use relayd. The one caveat is that this means that from the OpenBSD box, you need to be able to talk to the remote, private IPs without binding to a particular address. In relayd.conf, you enable relays on a port-by-port basis, so you can't allow blanket access.
Re: Using PF to NAT internal addresses over an IPSec link
On Fri, Aug 15, 2008 at 01:24:59PM +0900, william dunand wrote: Hi, I tried to reproduce what you want in my testing environment and managed to make it work. What you have to do is : - In your ipsec.conf, add an rule from your local network to the distant 172.25.0.1 (this rule is needed in order to route the traffic to enc0) Did you need to configure this on both ends? If I add a flow routing my network to the remote IP the packets never seem to get to enc0; it looks like isakmpd is stuck trying to negotiate something with the remove end. From what I can tell I need an SA for packets to get routed over enc0. In ipsec.conf I have: ike active esp from A.B.C.D to 172.25.0.1 peer W.X.Y.Z \ main auth hmac-md5 enc 3des \ quick auth hmac-md5 enc 3des group none \ psk yarg which lets me ping 172.25.0.1 from A.B.C.D. To route packets to 172.25.0.1 I am using flow from any to 172.25.0.1 peer W.X.Y.Z This does create appropriate encap entries in the routing tables, but I never see anything hit enc0.
Re: Using PF to NAT internal addresses over an IPSec link
On Fri, Aug 15, 2008 at 05:09:08PM +0900, william dunand wrote:
Of course, as it is a testing environment it is a lot easier to make
it work for me...
On the remote side, a configured something like this (I suppose they
have something of this kind on the other side) :
ike passive esp from 172.25.0.1 to A.B.C.D
And on the local server side, all I have is :
ike esp from any to 172.25.0.1 peer W.X.Y.Z
Ah, okay. It doesn't look like I have the luxury of simply saying
'from any to IP', since the remote end refuses to set up the SAs
in that case. I will try to get the other end to allow something
like that, since it seems like a MUCH better solution than the rube
goldberg stuff I'm playing with now, but half the reason I'm stuck
is the other guy doesn't return emails...
Never tried to use the flow directives as you did. I suppose that if
as you said you have correct encap routes, packets headed to
172.25.0.1 should definitely go through enc0, then if you set nat on
enc0, it should work as it does for me.
Could you paste and show us the output of netstat -rnf encap and also
if possible your pf.conf ?
Encap:
Source Port DestinationPort Proto
SA(Address/Proto/Type/Direction)
172.25.0.1/32 0 A.B.C.D/32 0 0 W.X.Y.Z/esp/use/in
A.B.C.D/32 0 172.25.0.1/32 0 0 W.X.Y.Z/esp/require/out
172.25.0.1/32 0 default0 0 W.X.Y.Z/esp/use/in
default0 172.25.0.1/32 0 0 W.X.Y.Z/esp/use/out
The pf.conf is pretty complicated, but the relevant rules that get hit are:
ext_if=bge1
int_if=bge0
vpn_if=enc0
set ruleset-optimization none
set state-policy if-bound
set skip on { lo }
scrub all fragment reassemble reassemble tcp
nat on $vpn_if from 192.168.0.0/16 to any - A.B.C.D
nat on $ext_if from 192.168.0.0/16 to any - E.F.G.H
block drop
pass quick on $vpn_if
pass quick on $int_if
And then there are others that eventually let us out of $ext_if as well.
Using PF to NAT internal addresses over an IPSec link
I have an IPSec connection set up to an external site, over which I have no control and whose topololgy I know nothign about (i.e. I don't know what subnets they use, etc.) Using ipsecctl, I have one flow set up, from my external IP A.B.C.D to an internal IP on their side, 172.25.0.1. I can ping 172.25.0.1 from the OpenBSD box, so IPSec is working fine. What I want to do is allow any machine from my internal networks to reach 172.25.0.1. What I would like to do is set up NAT, so that packets headed to the OpenBSD box from anywhere on my network get translated to A.B.C.D, which is then sent over the VPN connection. Unfortunately it looks like PF only applies NAT transforms when packets leave interfaces, not when they enter them, so packets come into the OpenBSD box with their private IPs, get routed out the interface associated with the default route, and only then get rewritten. Is there a better way to do this? I would like to be able to change which hosts on my side can go over the IPSec connection without having to coordinate with the other company, and without having to expose internal IP information. If you reply to the list please cc me as I am not subscribed.
