Mobile IPsec problem with iOS client

[bulgarion]

I've followed the tutorial for IPsec Mobile (http://doc.pfsense.org/index.php/Mobile_IPsec_on_2.0) to the letter - the first remote connection works fine, but - even if the IPsec tunnel comes up correctly - the traffic won't go through the tunnel after a few remote connections.

In the SAD status window I see several entries with zero data:

Source	Destination	Protocol	SPI	Enc. alg.	Auth. alg.	Data	
10.10.0.2[4500]	87.13.5.103[13619]	ESP-UDP	03539418	aes-cbc	hmac-sha1	0 B	 
10.10.0.2[4500]	87.13.5.103[13619]	ESP-UDP	0ffd2927	aes-cbc	hmac-sha1	0 B	 
10.10.0.2[4500]	87.13.5.103[13619]	ESP-UDP	039c4198	aes-cbc	hmac-sha1	0 B	 

Also, in the IPsec log window, I see several "failed to begin ipsec sa negotication"

Dec 29 16:37:55	racoon: ERROR: failed to begin ipsec sa negotication.
Dec 29 16:37:55	racoon: ERROR: no configuration found for 87.13.5.103.
Dec 29 16:37:33	racoon: ERROR: failed to begin ipsec sa negotication.
Dec 29 16:37:33	racoon: ERROR: no configuration found for 87.13.5.103.
Dec 29 16:37:18	racoon: ERROR: failed to begin ipsec sa negotication.
Dec 29 16:37:18	racoon: ERROR: no configuration found for 87.13.5.103.

I've tried switching the WAN connection as the listening interface (the pfSense manages two WAN connection for failovering) but with no effect - first connection is ok, regardless of how long it is, from the second on I couldn't send any traffic over the IPsec link.
I'm using the latest pfSense 2.0.2 on an ALIX board, clients are using both iOS 5 and 6 on iPads and iPhones.

[bulgarion]

I tried messing around, I believe the issue is related on how racoon manages the UDP encapsulation of ESP when NAT-T is used (I am behind double NAT and simple ESP packets on the pfSense are received but not sent). Sometimes, after the tunnel is dropped, a SAD is not deleted, thus making the reconnection from that client on that IP impossible until the expiry time is matched (or any other garbage collection method is applied).
Further client-side configuration is not an option (iOS isn't quite about "advanced settings"), so I think I have two roads to take:

• make the pfSense IPsec daemon a little smarter, allowing reconnections from the same IP within short time ranges (minutes)

• changing the WAN routers for a model that supports transparent ESP routing (Cisco), removing the need for NAT-T

…other ideas?

[ResIpsa]

I've noticed similar issues with my setup since I upgraded to 2.02. I can connect as many times as I want, but after the first connection, I can no longer connect to any of the hosts on my LAN. This also applies to connections made from my Ubuntu laptop. I followed the IPsec mobile tutorial as well. Rebooting pfsense fixes the problem.

[aleksandarm]

Hello. I'm confirming exactly the same behavior after upgrade to 2.0.2. On 2.0.1 Mobile IPSec worked as expected. Enabling/disabling the Mobile IPSec tunnel does not help. Restarting racoon helps, but this is not an option, since I have multiple site to site IPsec connections running.

[Clouseau]

UPDATE: Fixed and working: YOU HAVE TO REBOOT YOUR MOBILE AFTER INSTALLATION THE SCREWSOFT CLIENT (I did'nt do that)
Now I can access all my network resources, ping anything even disk shares etc…

Issues had pre-boot:
Yes - I have the same situation here. I use Screwsoft 2.2.0 VPN as mobile client. I can see also following messages in ipsec log:

Mar 6 09:53:52 	racoon: ERROR: failed to begin ipsec sa negotication.
Mar 6 09:53:52 	racoon: ERROR: no configuration found for 83.xxx.xxx.xxx.

What kind of configuration there should be available if it's missing?

Pacet capture from ipsec interface can see traffic: [10.0.222.100 is the mobile Client IP)
[code]09:56:04.649945 (authentic,confidential): SPI 0x09b6b32b: IP 10.0.222.100.57435 > 10.0.0.1.53: UDP, length 49
09:56:04.650311 (authentic,confidential): SPI 0x09b6b32b: IP 10.0.222.100.62619 > 10.0.0.1.53: UDP, length 49
09:56:04.650748 (authentic,confidential): SPI 0x09b6b32b: IP 10.0.222.100 > 10.0.0.1: ICMP echo request, id 1, seq 367, length 40
09:56:04.651044 (authentic,confidential): SPI 0x09b6b32b: IP 10.0.222.100.57435 > 10.0.0.10.53: UDP, length 49
09:56:04.651464 (authentic,confidential): SPI 0x09b6b32b: IP 10.0.222.100.62619 > 10.0.0.10.53: UDP, length 49
09:56:06.025861 (authentic,confidential): SPI 0x09b6b32b: IP 10.0.222.100 > 10.0.0.1: ICMP echo request, id 1, seq 368, length 40
This traffic is originated from Mobile client ping and dns query.

But LAN side does not see any traffic! I have rules that allow all the traffic from IPSEC to LAN (any any rule)

I have done like in this tutorial shown: http://doc.pfsense.org/index.php/IPsec_for_road_warriors_in_PfSense_2.0.1_with_PSK_in_stead_of_xauth

Any help on this awailable? Is there some bug or what?

[ResIpsa]

I have seen the issue with the built-in iOS VPN client and the NetworkManager client in Ubuntu. Rebooting those machines did not fix the issue. The only thing that fixes it is restarting raccoon.

[jkbrowne]

@Clouseau:

UPDATE: Fixed and working: YOU HAVE TO REBOOT YOUR MOBILE AFTER INSTALLATION THE SCREWSOFT CLIENT (I did'nt do that)
Now I can access all my network resources, ping anything even disk shares etc…

I'm glad got it working, but your issue is not really related to this thread.  Rebooting the client DOES NOT solve this problem.  This is an issue on the pfSense side, not the client side.

I am having the same issue on multiple devices.  I have configured the pfSense IPSEC service with a mobile configuration.  I can connect and establish a connection from iOS and from MacOS.  Traffic flows just fine through the tunnel to the internal network.  However, when I disconnect from the client, either iOS or MacOS, the SPD entries persist in pfSense, preventing reconnection until they expire.  After I disconnect the client, if I manually delete the SPD entries I can reconnect just fine.

I have created an ugly hack to work around this problem.  I have set up script and cron job (using minicron) which basically does a "setkey -D" and checks to see if there is an active connection.  If not, it runs "setkey -F -P", which clears the SPD entries allowing reconnection from the client(s).  This seems to work, but is not elegant in the least.

Anyone have thoughts on why this is happening?  Sounds like this wasn't an issue with 2.0.1?

Thanks,
John

[dhatz]

@jkbrowne:

I am having the same issue on multiple devices.  I have configured the pfSense IPSEC service with a mobile configuration.  I can connect and establish a connection from iOS and from MacOS.  Traffic flows just fine through the tunnel to the internal network.  However, when I disconnect from the client, either iOS or MacOS, the SPD entries persist in pfSense, preventing reconnection until they expire.  After I disconnect the client, if I manually delete the SPD entries I can reconnect just fine.

Sounds like a regression from 2.0.1 to 2.0.2 … Could you try your config with a 2.0.3 snapshot (or 2.1-BETA) ?

[jkbrowne]

Sounds like a regression from 2.0.1 to 2.0.2 … Could you try your config with a 2.0.3 snapshot (or 2.1-BETA) ?

Hi dhatz,

Thanks for the reply.  I actually just installed 2.1 BETA (yesterday's build) and it appears to have the same problem.

[jkbrowne]

Just an FYI, here's another thread where a-couple of folks are having the same issue (no suggested solutions though):

http://forum.pfsense.org/index.php/topic,59008.0.html

Thoughts anyone?

[gamejia]

It appears to be an issue with 2.0.3 where IPSec with PSK + xauth tunnels are not cleaned after the client disconnects (it never gets cleaned, I left pfsense running overnight and it is still an issue). Restarting the racoon service allows the client to reconnect one more time and restarting pfsense does that also.

For my organization, IPSec with Mutual PSK + xauth is a must because we migrated from a Cisco Router and all of our employees still have the Cisco Client on Windows or Use the "Cisco IPSec" option on Mac.

Could one of somebody post a patch or workaround? For some reason running "setkey -F -P" still doesn't fix the problem, only restarting the service does.

Thanks

gamejia

[gamejia]

For those interested in a very ugly workaround, I created a script that runs every 5 minutes (using cron) and cleans up the IPSec SAD and SPD entries if there are no users using IPSec.

#!/bin/sh
PATH=/usr/bin:/usr/sbin:.
showUsers=/usr/local/sbin/racoonctl show-users | wc -l
setKeyD=/usr/local/sbin/setkey -D | wc -l
setKeyDP=/usr/local/sbin/setkey -DP | wc -l

if /bin/[ $showUsers -ge 2 ]; then
  echo "FixIPSec.sh: There are clients connected, cannot fix IPSec"
elif /bin/[ $setKeyD -ge 2 ] || [ $setKeyDP -ge 2 ]; then
  echo "FixIPSec.sh: Fixing IPSec $setKeyD $setKeyDP"
  /usr/local/sbin/setkey -F
  /usr/local/sbin/setkey -FP
else
  echo "FixIPSec.sh: nothing to fix"
fi

Please keep in mind that this is still a WIP and I plan on cleaning it up more in the future if no fix is available. I plan on comparing the entries returned by "setkey -Da" and "setkey -DPa" to the values returned by racoonctl and only remove the SPD entries that are causing problems.

[marquivon]

@gamejia:

For those interested in a very ugly workaround, I created a script that runs every 5 minutes (using cron) and cleans up the IPSec SAD and SPD entries if there are no users using IPSec.

<snip>Please keep in mind that this is still a WIP and I plan on cleaning it up more in the future if no fix is available. I plan on comparing the entries returned by "setkey -Da" and "setkey -DPa" to the values returned by racoonctl and only remove the SPD entries that are causing problems.</snip>

Thank you for posting the script. It has been really helpful, and has made the VPN usage in our small network more predictable.

Ideally this should be handled at the pfsense end without using this workaround, considering if there are more number of users, then things can get complicated. I was not able to find any bug-report for this; is anyone aware of any bug report filed - else I'll go ahead and do it.