OpenVPN clients reaching remote IPSEC sites via central pfsense host

sporkme

I think I have this working, but I don't quite understand what I've done to make it work.

An overview:

pfsense box at a central site (2.1.4 Release) running OpenVPN server and an IPSEC tunnel to another site. The remote IPSEC site has a box running FreeBSD 8.4/racoon which straddle both an external and internal network.

Clients that connect via OpenVPN to the pfsense box want to reach both a local internal network and the remote IPSEC-connected internal network. The IPSEC tunnel between both sites is operational and used regularly. Before I started working on this, openvpn clients could not reach anything at the remote IPSEC-connected site - traceroutes would show a first hop of the OpenVPN interface on the pfsense box and then would follow the default route out to the public internet.

Networks in question - 192.168.11.0/24, internal network at pfsense site, 10.99.88.0/24, internal network at the remote site connected via IPSEC tunnel, 10.200.200.0/24, OpenVPN interface range.

What I've done is added another "phase 2" entry to the IPSEC configuration. On the pfsense end, I have the following entered:

Mode - Tunnel IPv4
Local Network
- type, network - 10.200.200.0/24
- "specify the address to be translated" option - type, address - 192.168.11.251
Remote Network
- type, network - 10.99.88.0/24

On the remote side, I added an "sainfo" stanza like this in racoon.conf:

sainfo address 10.99.88.0/24 any address 192.168.11.251/32 any {
        encryption_algorithm aes256,3des,blowfish,cast128,rijndael;
        authentication_algorithm hmac_sha1,hmac_md5;
        compression_algorithm deflate;
        pfs_group 2;
        lifetime time 3600 secs;
}

This works. Some options that did not work were - specifying a /32 instead of "address" in the NAT section, specifying a /24 in the NAT section, and specifying a /24 in the above snippet from the remote kind of worked, but I ended up breaking connectivity from the remote site back to the pfsense site over the tunnel.

I'm puzzled as to what the "In case you need NAT/BINAT on this network specify the address to be translated" section really does behind the scenes. I'm also confused by the second phase 2 config in the remote racoon config, as it seems to overlap the first.

It does work though…

cmb

It's odd because of the way it has to work. It has to match pre-NAT for the traffic to hit the portion of the kernel that's processing the IPsec. But the NAT portion is the only thing you're presenting on the P2 to the remote end. So it has both, hits pre-NAT, gets NATed, gets sent out.

You don't need or want NAT in this case though, just add another phase 2 on both ends matching the tunnel network source.

sporkme

@cmb:

It's odd because of the way it has to work. It has to match pre-NAT for the traffic to hit the portion of the kernel that's processing the IPsec. But the NAT portion is the only thing you're presenting on the P2 to the remote end. So it has both, hits pre-NAT, gets NATed, gets sent out.

You don't need or want NAT in this case though, just add another phase 2 on both ends matching the tunnel network source.

I'm lazy, so I do want to NAT. :)

The remote end has a box terminating the tunnel, but it is not the default route. So if I wanted to use the OpenVPN block without NAT, I'd have to do another round of static route wrangling to get the return traffic pointed at the remote IPSEC gateway instead of the default internet gateway.