IPSEC tunnels stopped working after upgrade from 2.5.1 to 2.5.2
-
HI, I have a pfsense virtuale machine. It was installed a few months back (2.5), later upgraded to 2.5.1 and now to 2.5.2
I have 3 IPSEC VPN tunnels going into 3 other pfsense firewalls. The tunnels where working fine until the upgrade, but stopped working after the upgrade. Even when I delete the tunnel and add it again, it is not coming up. I could have made all kinds off errors, but the only thing I did was upgrade. Everything else seems to be working fine (port forwarding, dhcp). I used the recipe settings from Netgate for a site to site VPN (phase1: AES128-GCM (128 bits) AES-XCBC 14 (2048 bit), phase 2: ESP AES128-GCM (128 bits) )
When I look at the log:
Jul 12 07:52:34 charon 47285 14[NET] <5717> received packet: from aaa.aaa.aaa.aaa[500] to bbb.bbb.bbb.bbb[500] (456 bytes)
Jul 12 07:52:34 charon 47285 14[ENC] <5717> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Jul 12 07:52:34 charon 47285 14[CFG] <5717> looking for an IKEv2 config for bbb.bbb.bbb.bbb...aaa.aaa.aaa.aaa
Jul 12 07:52:34 charon 47285 14[IKE] <5717> no IKE config found for bbb.bbb.bbb.bbb...aaa.aaa.aaa.aaa, sending NO_PROPOSAL_CHOSEN
Jul 12 07:52:34 charon 47285 14[ENC] <5717> generating IKE_SA_INIT response 0 [ N(NO_PROP) ]
Jul 12 07:52:34 charon 47285 14[NET] <5717> sending packet: from bbb.bbb.bbb.bbb[500] to aaa.aaa.aaa.aaa[500] (36 bytes)
Jul 12 07:52:34 charon 47285 14[IKE] <5717> IKE_SA (unnamed)[5717] state change: CREATED => DESTROYING -
@mathijsk Same issue here on 3 different systems, I had to roll-back 2 systems from version 2.5.2 to version 2.5.1 to restore the IPSec tunnels.
I kept one on 2.5.2 so I can perform some tests. I also opened a bug on redmine but has been rejected (https://redmine.pfsense.org/issues/12136#change-55126).
The point is, on version 2.5.2 there is something that breaks the StrongSwan configuration in my case. It happened that after the upgrade the Mobile Warrior IPSec VPN did not work anymore, than after just one "save" leaving the same parameters all the VPN tunnels stopped to work.
Playing with the VPN settings somehow restored the tunnels, but changing some Mobile Warrior parameter broke the configuration again.The log I have is similar to yours (for the Mobile Warrior VPN):
Jul 16 11:08:29 charon 10667 07[NET] <con-mobile|32738> sending packet: from <pfSensePublicIP>[500] to 37.159.85.106[53594] (396 bytes) Jul 16 11:08:29 charon 10667 07[IKE] <con-mobile|32738> sending retransmit 2 of response message ID 0, seq 1 Jul 16 11:08:22 charon 10667 07[NET] <con-mobile|32738> sending packet: from <pfSensePublicIP>[500] to 37.159.85.106[53594] (396 bytes) Jul 16 11:08:22 charon 10667 07[IKE] <con-mobile|32738> sending retransmit 1 of response message ID 0, seq 1 Jul 16 11:08:18 charon 10667 07[IKE] <con-mobile|32738> queueing INFORMATIONAL_V1 request as tasks still active Jul 16 11:08:18 charon 10667 07[NET] <con-mobile|32738> received packet: from 37.159.85.106[53594] to <pfSensePublicIP>[500] (84 bytes) Jul 16 11:08:18 charon 10667 07[NET] <con-mobile|32738> sending packet: from <pfSensePublicIP>[500] to 37.159.85.106[53594] (396 bytes) Jul 16 11:08:18 charon 10667 07[ENC] <con-mobile|32738> generating AGGRESSIVE response 0 [ SA KE No ID V V V V NAT-D NAT-D HASH ] Jul 16 11:08:18 charon 10667 07[CFG] <32738> selected peer config "con-mobile" Jul 16 11:08:18 charon 10667 07[CFG] <32738> looking for XAuthInitPSK peer configs matching <pfSensePublicIP>...37.159.85.106[CasaMik] Jul 16 11:08:18 charon 10667 07[CFG] <32738> selected proposal: IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024 Jul 16 11:08:18 charon 10667 07[IKE] <32738> 37.159.85.106 is initiating a Aggressive Mode IKE_SA Jul 16 11:08:18 charon 10667 07[IKE] <32738> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID Jul 16 11:08:18 charon 10667 07[IKE] <32738> received NAT-T (RFC 3947) vendor ID Jul 16 11:08:18 charon 10667 07[IKE] <32738> received FRAGMENTATION vendor ID Jul 16 11:08:18 charon 10667 07[IKE] <32738> received Cisco Unity vendor ID Jul 16 11:08:18 charon 10667 07[IKE] <32738> received DPD vendor ID Jul 16 11:08:18 charon 10667 07[IKE] <32738> received XAuth vendor ID Jul 16 11:08:18 charon 10667 07[ENC] <32738> parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V ] Jul 16 11:08:18 charon 10667 07[NET] <32738> received packet: from 37.159.85.106[53594] to <pfSensePublicIP>[500] (627 bytes)At the moment I have no other details, but I can perform all the checks needed to identify the issue.
Thanks,
Michele -
@mdima Thank you, I have solved it (in my config). On my WAN I had IPv6 on DHCP. I set this to disabled and everything started working right away. Never used any IPv6, so not sure what changed, but I am happy I have solved it in my config. Thank you for you help!
-
@mathijsk Thank you for your feedback.
I double checked, I do not have any IPv6 configuration on any interface of all my systems, both the ones 2.5.1 and 2.5.2.
Anyway, thank you for the hint!
Michele
-
Hello,
maybe I found out what the problem is playing with the IPSec VPN Settings.In the IPSec Tunnels I had a "dead" tunnel, I mean a tunnel that was still enabled in pfSense but probably has been removed from the other side (a customer). So the connections to that tunnel did not work.
If I disable that dead IPSec Tunnel the Mobile Warrior VPN works! If I just re-enable that tunnel it does not work anymore (without changing any other parameter).
So it seems that a non-working tunnel impacts on the Mobile Warrior VPN.
Does anyone is able to replicate the same behavior?
Thanks,
Michele -
I am trying to understand the differences between the two situations, so I analyzed the two swanctl.conf files and compared them.
It seems that with the "not working" tunnel pfSense just adds more lines to the config, it does not affects the rest of the configuration.
The only thing that comes to my mind is that when enabling the "not working" tunnel, the Mobile Warrior tunnel settings are not the last ones saved in the config.Removing the sensitive information from the config files, I have:
# This file is automatically generated. Do not edit connections { bypass { remote_addrs = 127.0.0.1 } con1000 { fragmentation = yes unique = replace version = 2 proposals = 3des-md5-modp1024 dpd_delay = 10s dpd_timeout = 60s rekey_time = 77760s reauth_time = 0s over_time = 8640s rand_time = 8640s encap = yes mobike = no local_addrs = <local WAN IP> remote_addrs = <Remote Addr 1> local { id = <local WAN IP> auth = psk } remote { id = <Remote Addr 1> auth = psk } children { con1000 { dpd_action = trap mode = tunnel policies = yes life_time = 3600s rekey_time = 3240s rand_time = 360s start_action = trap remote_ts = 192.168.0.0/24,10.0.3.0/24,192.168.20.0/24,10.0.1.0/24,10.20.0.0/16 local_ts = 192.168.22.0/24,192.168.22.0/24,192.168.22.0/24,192.168.22.0/24,192.168.22.0/24 esp_proposals = aes256gcm128-modp1024,aes256gcm96-modp1024,aes256gcm64-modp1024 } } } con300000 { fragmentation = yes unique = replace version = 1 aggressive = no proposals = aes256-sha1-modp1024 dpd_delay = 10s dpd_timeout = 60s reauth_time = 25920s over_time = 2880s rand_time = 2880s encap = no mobike = no local_addrs = <local WAN IP> remote_addrs = <Remote Addr 2> local { id = <local WAN IP> auth = psk } remote { id = <Remote Addr 2> auth = psk } children { con300000 { dpd_action = trap mode = tunnel policies = yes life_time = 36000s rekey_time = 32400s rand_time = 3600s start_action = trap local_ts = 192.168.22.0/24 remote_ts = 10.239.1.0/24 esp_proposals = aes256gcm128,aes256gcm96,aes256gcm64 } con300001 { dpd_action = trap mode = tunnel policies = yes life_time = 36000s rekey_time = 32400s rand_time = 3600s start_action = trap local_ts = 192.168.22.0/24 remote_ts = 10.239.2.0/24 esp_proposals = aes256gcm128,aes256gcm96,aes256gcm64 } con300002 { dpd_action = trap mode = tunnel policies = yes life_time = 36000s rekey_time = 32400s rand_time = 3600s start_action = trap local_ts = 192.168.22.0/24 remote_ts = 10.239.3.0/24 esp_proposals = aes256gcm128,aes256gcm96,aes256gcm64 } } } con-mobile : con-mobile-defaults { # Stub to load con-mobile-defaults } con200000 { fragmentation = yes unique = replace version = 1 aggressive = yes proposals = 3des-md5-modp1024 dpd_delay = 10s dpd_timeout = 60s reauth_time = 77760s over_time = 8640s rand_time = 8640s encap = no mobike = no local_addrs = <local WAN IP> remote_addrs = <Remote Addr 3> local { id = <local WAN IP> auth = psk } remote { id = <Remote Addr 3> auth = psk } children { con200000 { dpd_action = trap mode = tunnel policies = yes life_time = 28800s rekey_time = 25920s rand_time = 2880s start_action = trap local_ts = 192.168.22.0/24 remote_ts = 10.0.16.156/32 esp_proposals = aes256-sha1-modp1024 } con200001 { dpd_action = trap mode = tunnel policies = yes life_time = 28800s rekey_time = 25920s rand_time = 2880s start_action = trap local_ts = 192.168.22.0/24 remote_ts = 10.8.137.0/24 esp_proposals = aes256-sha1-modp1024 } } } } con-mobile-defaults { fragmentation = yes unique = replace version = 1 aggressive = yes proposals = 3des-md5-modp1024,aes256-sha1-modp1024 dpd_delay = 10s dpd_timeout = 60s reauth_time = 77760s over_time = 8640s rand_time = 8640s encap = yes mobike = no local_addrs = <local WAN IP> remote_addrs = 0.0.0.0/0,::/0 pools = mobile-pool-v4 local { id = <local WAN IP> auth = psk } remote-1 { auth = psk } remote-2 { auth = xauth-generic } children { con-mobile { dpd_action = clear mode = tunnel policies = yes life_time = 28800s rekey_time = 25920s rand_time = 2880s start_action = none local_ts = 192.168.22.0/24 esp_proposals = aes256-md5,aes256-sha1,aes192-md5,aes192-sha1,aes128-md5,aes128-sha1,3des-md5,3des-sha1 } } } pools { mobile-pool-v4 : mobile-pool { addrs = 192.168.88.0/24 subnet = 192.168.22.0/24 split_include = 192.168.22.0/24 } } mobile-pool { # Mobile pool settings template dns = 192.168.22.1 # Search domain and default domain 28674 = "<local domain>" 28675 = "<local domain>" 28672 = "Welcome to IPSec VPN" 28673 = 1 } secrets { ike-0 { secret = xxxxxxxxxxxxxxxxxxxxxx id-0 = %any id-1 = <Remote Addr 1> } ike-1 { secret = yyyyyyyyyyyyyyyyyyyyyy id-0 = %any id-1 = <Remote Addr 2> } ike-2 { secret = 0sdnBuY2EkYQ== id-0 = <local WAN IP> id-1 = fqdn:CasaMik } ike-3 { secret = zzzzzzzzzzzzzzzzzzzzzz id-0 = <local WAN IP> id-1 = %any } ike-4 { secret = tttttttttttttttttttttt } ike-5 { secret = wwwwwwwwwwwwwwwwwwwwww id-0 = %any id-1 = <Remote Addr 3> } }the difference between "not working tunnel enabled" (mobile warrior VPN not working) and "not working tunnel enabled disabled" (mobile warrior VPN working) are the nodes:
- con200000 (and all its children)
- ike-5.
Does anyone has an idea why enabling the con200000 tunnel the Mobile Warrior VPN does not work?
Thanks,
Michele -
@mathijsk Thank you for posting this! I, too, had all my IPSec tunnels go down, but I didn't realize it because I very rarely use them. Meanwhile, I was trying to setup a "Mobile Clients" vpn and have been banging my head against the wall for a few weeks now getting stuck with vague errors and no working connections. I, too, had not configured IPv6 and when I checked my WAN interface it was setup for DHCP6. When I set that to None, everything came back up. I don't know how it got set to DHCP6 as my ISP does not provide addresses with DHCP, so it must have gotten switched on with some update.
