pfSense and IPsec

Thu 19 May 2011

Filed under Sec.

Tags IPsec Lamer Moments Security

Practical Troubleshooting

I love pfSense. So far it's superior to every Linux-based routing appliance. No product is perfect, but the 2.0 release is very promising. I have been troubleshooting tunnels which inexplicably do not work. I have been recieving the following error during phase1 connection:

racoon: ERROR: couldn't find configuration

This usually means a significant mismatch exists in phase1 negotiations. Despite my meticulous efforts the tunnels would not start. I watched the IPsec logs hopelessly, trying many different things. What finally worked was connecting to the console, killing racoon and starting it manually as follows:

racoon -d -v -F -f /var/etc/racoon.conf

By monitoring the output, I discovered during debugging that the packets were coming from the wrong source IP address. One of my sites has multiple WAN links, and racoon was using the wrong source address for IPsec negotiation. The phase1 arrival was clearly logged and rejected - because it didn't match any existing configuration.

Once complete, I was quickly able to determine what to do. However, if you don't have access to a host behind the pfSense firewall then you may have problems creating IPsec tunnels. I used this to force a packet:

My firewall's LAN address, which is part of the IPsec local subnet scope, is The remote network is I need to create a single packet from to something in 10.1.1.x.

ping -S -c 1

What could be better.

Feedback for improvement would begin with one admonition: Don't trust the log output of Racoon. I should have used TCP-dump on both ends, watching for packets setting up sessions.

[2.0-RC1][]/root(1): tcpdump -ni re0 port 500
16:39:07.697695 IP > isakmp: phase 2/others I inf[E]
16:40:26.980944 IP > isakmp: phase 1 I agg
16:40:36.982740 IP > isakmp: phase 1 I agg
16:40:46.983927 IP > isakmp: phase 1 I agg
16:40:56.985122 IP > isakmp: phase 1 I agg
16:41:06.986307 IP > isakmp: phase 1 I agg

Had I done this at both ends, I would have clearly seen that the wrong interface was emitting packets. *Both* ends. That was my mistake. I trusted logs at Site-A, and I never verified my problem at Site-B. Hours of painstaking troubleshooting for no good reason.

Work Around

My current imperfect workaround is to add the following line to each of my remote sites crontab:

# cat crontab|grep newsys
*       *       *       *       *       root    /sbin/ping -S -c

Obviously I turfed this above, I just thought I would share it with everyone. This has the net effect of a 60 second tunnel keep alive. May not be appropriate for some environments. Good luck.


Up To Something © Joshua M Schmidlkofer Powered by Pelican and Twitter Bootstrap. Icons by Font Awesome and Font Awesome More