IPSEC Between pfSense and FreeBSD 7

dapriv

I have a box running pfSense at work and I am running FreeBSD 7 at home. I have successfully setup an IPSEC tunnel between two boxes running pfSense, and between two FreeBSD boxes, but I am unable to get IPSEC working between pfSense and the FreeBSD box (running racoon). While I think I have most of the config down, the part that is messing me up is the interface since FreeBSD doesn't have enc interfaces and the gif interface seems to require more configuration than enc. Can anyone point me in the direction of a HOWTO that I'm missing (or offer a hand)?

Thanks,
Matt

dapriv

I found my mistake and no longer require assistance.

jimp

Good to hear you got this working.

It would be helpful for others if you would post more information about how you managed to fix the problem, in case someone else has the same problem in the future.

Thanks!

sporkme

@jimp:

It would be helpful for others if you would post more information about how you managed to fix the problem, in case someone else has the same problem in the future.

Like me…

I've got pfSense to pfSense tunnels, but I now want to create one to a 7.3 box. I'm not even sure where to start. I have two ports that promise to make this easier - either "racoon2" or "ipsec-tools". Which is a better choice when the other end is a FreeBSD box? Any good starting points for this?

dapriv

My intent is to write a HOWTO on how to do this – I just haven't gotten around to it yet. In the mean time start with the FreeBSD IPSEC tutorial, located here: http://www.freebsd.org/doc/en/books/handbook/ipsec.html

There are a few things you need to change in there. If you look at the racoon and ispec configs on the pfSense box (located in /var/etc, called racoon.conf, psk.conf, spd.conf) and compare them to the entries on the IPSEC tutorial hopefully you can see the differences. It took me a bit to figure it out. If not, well, I'm going to try and write my HOWTO this afternoon if I can. I just can't guarantee that something won't come up that stops me from getting it done.

-Matt

dapriv

Ok. A draft of instructions is online at: http://www.kaydongroup.com/~mbrennan/bsdpfsenseipsec.pdf. I'd appreciate feedback as I'm not really used to writing these kinds of things.

Thanks,
Matt

sporkme

@dapriv:

Ok. A draft of instructions is online at: http://www.kaydongroup.com/~mbrennan/bsdpfsenseipsec.pdf. I'd appreciate feedback as I'm not really used to writing these kinds of things.

It looks great to me.

I did follow the instructions, and I am getting close - the tunnel starts to come up, and the first phase of the negotiation works, but on the second I get this when debugging the non-pfsense end:


2010-07-09 02:49:15: DEBUG: configuration found for 5.6.7.8.
2010-07-09 02:49:15: DEBUG: getsainfo params: loc='192.168.1.0/24', rmt='192.168.11.0/24', peer='5.6.7.8', id=0
2010-07-09 02:49:15: DEBUG: getsainfo pass #1
2010-07-09 02:49:15: DEBUG: evaluating sainfo: loc='192.168.1.111/24', rmt='192.168.11.1/24', peer='ANY', id=0
2010-07-09 02:49:15: DEBUG: getsainfo pass #2
2010-07-09 02:49:15: DEBUG: evaluating sainfo: loc='192.168.1.111/24', rmt='192.168.11.1/24', peer='ANY', id=0
2010-07-09 02:49:15: DEBUG: check and compare ids : value mismatch (IPv4_subnet)
2010-07-09 02:49:15: DEBUG: cmpid target: '192.168.1.0/24'
2010-07-09 02:49:15: DEBUG: cmpid source: '192.168.1.111/24'
2010-07-09 02:49:15: ERROR: failed to get sainfo.
2010-07-09 02:49:15: ERROR: failed to get sainfo.
2010-07-09 02:49:15: ERROR: failed to pre-process packet.
2010-07-09 02:49:15: DEBUG: IV freed

The remote's (pfsense) public IP here would be 5.6.7.8. The subnet on that end is 192.168.11.0/24 and pfsense's LAN IP for that network is 192.168.11.1/24.

The local (freebsd) public IP would be 1.2.3.4. The subnet on that end is 192.168.1.0/24 and the LAN IP on that box is 192.168.1.111/24.

My racoon.conf on the freebsd side looks like this:


path pre_shared_key "/usr/local/etc/racoon/psk.txt";

remote 5.6.7.8 {
        exchange_mode aggressive;
        my_identifier address "1.2.3.4";

        peers_identifier address 5.6.7.8;
        initial_contact on;

        ike_frag on;
        support_proxy on;
        proposal_check obey;

        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
                lifetime time 28800 secs;
        }
        lifetime time 28800 secs;
}

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

My setkey.conf looks like this:


flush;
spdflush;
spdadd 192.168.1.0/24 192.168.1.111/32 any -P in none;
spdadd 192.168.1.111/32 192.168.1.0/24 any -P out none;
spdadd 192.168.1.0/24 192.168.11.0/24 any -P out ipsec esp/tunnel/1.2.3.4-5.6.7.8/unique;
spdadd 192.168.11.0/24 192.168.1.0/24 any -P out ipsec esp/tunnel/5.6.7.8-1.2.3.4/unique;

No mismatches here are jumping out at me…

dapriv

@sporkme:


2010-07-09 02:49:15: DEBUG: configuration found for 5.6.7.8.
2010-07-09 02:49:15: DEBUG: getsainfo params: loc='192.168.1.0/24', rmt='192.168.11.0/24', peer='5.6.7.8', id=0
2010-07-09 02:49:15: DEBUG: getsainfo pass #1
2010-07-09 02:49:15: DEBUG: evaluating sainfo: loc='192.168.1.111/24', rmt='192.168.11.1/24', peer='ANY', id=0
2010-07-09 02:49:15: DEBUG: getsainfo pass #2
2010-07-09 02:49:15: DEBUG: evaluating sainfo: loc='192.168.1.111/24', rmt='192.168.11.1/24', peer='ANY', id=0
2010-07-09 02:49:15: DEBUG: check and compare ids : value mismatch (IPv4_subnet)
2010-07-09 02:49:15: DEBUG: cmpid target: '192.168.1.0/24'
2010-07-09 02:49:15: DEBUG: cmpid source: '192.168.1.111/24'
2010-07-09 02:49:15: ERROR: failed to get sainfo.
2010-07-09 02:49:15: ERROR: failed to get sainfo.
2010-07-09 02:49:15: ERROR: failed to pre-process packet.
2010-07-09 02:49:15: DEBUG: IV freed

While 192.168.1.111/24 and 192.168.1.0/24 are the same subnet, I think Racoon interprets them as strings and not actually as a CIDR subnet so it sees them as a mismatch. Try changing all instances of 192.168.1.111/24 to 192.168.1.0/24 and see what happens. Of course, any place you have the actual IP of 192.168.1.111 (or 192.168.1.111/32) would need to stay that way.

-Matt

sporkme

@dapriv:

While 192.168.1.111/24 and 192.168.1.0/24 are the same subnet, I think Racoon interprets them as strings and not actually as a CIDR subnet so it sees them as a mismatch. Try changing all instances of 192.168.1.111/24 to 192.168.1.0/24 and see what happens. Of course, any place you have the actual IP of 192.168.1.111 (or 192.168.1.111/32) would need to stay that way.

That did it. After that change, I was able to get traffic back and forth between the internal networks of the two endpoints, but still had an error:


 racoon: NOTIFY: no in-bound policy found: 192.168.11.0/24[0] 192.168.1.0/24[0] proto=any dir=in

That was because of this obvious typo that I missed; the second line should have had "in" rather than "out":


spdadd 192.168.1.0/24 192.168.11.0/24 any -P out ipsec esp/tunnel/1.2.3.4-5.6.7.8/unique;
spdadd 192.168.11.0/24 192.168.1.0/24 any -P out ipsec esp/tunnel/5.6.7.8-1.2.3.4/unique;

For the author of the pdf, note that the two "out" lines appear in the first setkey example, but not the second. :)

Something is still a bit off, but my setup is odd in that my vpn "router" is just a box sitting in a datacenter - it's not a "router", so all the other boxes will need a static route to find their way to the vpn server when trying to reach the far end of the vpn.

sporkme

And it all works. The last hiccup I had was that when I was pinging from a host on the 192.168.1.0/24 lan, I could see the traffic leave, but not come back. Running tcpdump on gif0 showed that the packets were returning via the tunnel, but not making it out to the local lan.

After much head-scratching, I realized that the "setkey" command is not run by racoon's rc.d script, but by /etc/rc.d/ipsec. After issuing a reload and getting the spd stuff re-read, everything works.

Now to login to a dozen and a half boxes and add a static route…

dapriv

@sporkme:

For the author of the pdf, note that the two "out" lines appear in the first setkey example, but not the second. :)

The PDF has been updated. Sorry for the typo.

@sporkme:

Now to login to a dozen and a half boxes and add a static route…

You can't just add a static route to the router? Maintaining static routes on multiple machines generally leads to headaches.

-Matt

sporkme

@dapriv:

You can't just add a static route to the router?

Nope. This is a colo setup, so no, we don't have access to the router. Just another line to stash in our default rc.conf…