IPSEC client from behind 2x-2.1

kejianshi

Are there any differences in settings between the pfsense and ddwrt ipsec server?
More specifically, what settings are you using in pfsense?

pinoyboy

As far as the settings from home setup, they are stock. The only item change is the local ip of subnet and password of admin; at home for both DD-WRT and pfSense. For the 4 remote pfSense (3 are 1.2.3 and 1 id 2.0.3); they are identical in that I have VIP and 1:1 setup; they all have static ips and IPSEC enabled for VPN. These are very generic or nothing exotic. The item that I listed pertaining the IPSEC racoon issue has been persistent, but seems to be "triggered" by 2 pfSense from end to end. I provided numerous permutations, but I will not be changing the remote sites or various clients network to diagnose further.

kejianshi

Weird - pfsense normally works better pfsense IPsec end to end than from pfsense to other.

However, if you are looking for a much easier end to end setup using pfsense (more memory, more processor = more throughput I presume) then give end to end openvpn a try. Its very well established as working and less fidley than IPsec. IPsec is nice, but going end to end with pfsense or even including DDWRT in the mix, I just like openvpn better.

pinoyboy

Well, this is not pfSense end to end IPSEC; not router to router connection. This is IPSEC client behind a pfSense FW connecting to a pfSense FW router. Redmine clearly shows this is an issue for more than 2 + years - http://redmine.pfsense.org/issues/1351. With regards to OpenVPN, I wish I could right now however, since home DD-WRT resolves the issue, I am not going to change client sites just for this issue of mine. I am merely reporting an issue that's already known and confirming that it still exists with latest snapshot.

** The more I look at the IPSEC section of the Forum, the more I realize there are serious similar reports of connecting IPSEC client with no traffic; too many.

kejianshi

I have no idea, but I wonder if rewriting of packets at would make a difference all.
Like using "static" setting on the outbound NAT would matter because static port is the norm on most other routers but not pfsense.
So, maybe setting "static" on manual outbound NAT would unbreak your setup.
It fixes a few anomalies for me.

P.S. pinoyboy is better than pinayboy as a username.

pinoyboy

I tried the MANUAL NAT: Outbound also on my end for all the version of pfSense I installed. Results are the same. This is a tedious test because I ensure I have a clean test by rebooting my network (power off) and restarting the remote racoon service.

kejianshi

I don't mean manual outbound NAT.
I mean manual outbound NAT with "Static" option checked.
Maybe will make no difference, but sure un-breaks SIP for one.

pinoyboy

That permutation was already tried. No issue with SIP Traffic / FTP or any other service except the IPSEC I reported.

kejianshi

You know what? I do see that behavior on the only device I ever connect to IPsec through PFsense. My cellphone.
I connect, and all is well. No problems (After an exhausting process of creative discovery)
Then if the line drops or I disconnect and reconnect the phone, I may or may not have a functioning ipsec tunnel. Its hit and miss.

I'm going to play with the advanced configs to see if I can make this stable for me.
I don't, myself, have a good use for IPsec, but I like it to function incase someone ever needs it from me.

kejianshi

OK - Settings seem to make no difference.
While connected everything is great.
After disconnecting and waiting a couple minutes it will reconnect but not pass traffic.
A very long disconnect period will allow a reconnect, no problem.
Short disconnects / reconnects are the issue.

Originally I had thought this was being caused by some weirdness of mobile internet.
Now I see there is a something up with raccoon on my pfsense causing it.

pinoyboy

Final confirmation on IPSEC issues:

I have been using 1.2.3, 2.0.3, and latest snapshot as my SOURCE at home to connect to DESTINATIONS sites ranging from pfSense 1.2.3 to 2.0.3. No problem connecting to 1.2.3 remote sites via IPSEC. I finally reproduced consistently that destination must be 2.0.3 (perhaps the 2.x tree even ) for IPSEC connection to eventually time out; where connection still works but no routing or name resolution occur after second reconnect attempt (after several minutes).

If my source is DD-WRT, it does not matter whether I am connecting to destination 1.2.3 or 2.0.3, it works always. I tried all types of Shrewsoft client settings and pfSense settings (type of cipher, DPD, NAT-T, etc - results are the same). You must restart racoon service to get back to normal.

You can reproduce this IPSEC issue by being behind 1.2.3 - to current snapshot and you connect to a remote 2.x site using Shrewsoft VPN client and waiting to reconnect 5 minutes or later - you will lose routing and obviously name resolution. From my readings here, this not only affects IPSEC client connections, but even IPSEC VPN Site to site (I have not personally tested this scenario). I am done testing this - I am 100% certain of this issue.

http://redmine.pfsense.org/issues/1351 still exists.

kejianshi

IPsec fails to pass traffic when disconnected and then reconnected until raccoon service is restarted:

I went into my logs and I noticed that there is a common thing that is going on whenever this happens:

racoon: ERROR: no configuration found for (I deleted the IP)
racoon: ERROR: failed to begin ipsec sa negotication

I also noticed that a restart of the raccoon process, without requiring a logout/login cycle of the client corrects the issue until next disconnect.

I also ran across this script to restart raccoon in the event of a WAN IP change.
http://wiki.openwrt.org/doc/howto/vpn.ipsec.basics.racoon

#!/bin/sh

ListenInterface() {
local iface="$1"
if [ "$INTERFACE" = "$iface" ]; then
/etc/init.d/racoon restart
fi
}

RacoonInstance() {
config_list_foreach "$1" listen ListenInterface
}

if [ "$ACTION" = "ifup" ]; then
config_load racoon
config_foreach RacoonInstance racoon
fi

So, what I was wondering about is killing two birds with one stone.
Rewrite this script a bit and apply it on pfsense to check for WAN IP changes that break IPsec and to also
check the IPsec logfile for instances of:
"racoon: ERROR: no configuration found for"
"racoon: ERROR: failed to begin ipsec sa negotication"

and then empty the log and restart raccoon if found.

What do you think? Anyone?

kejianshi

Everybody wants to know how to get IPsec clients to reconnect reliably after a drop or disconnect, but no one has a comment?
I hear crickets chirping…