Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    IPSEC tunnels stopped working after upgrade from 2.5.1 to 2.5.2

    Scheduled Pinned Locked Moved IPsec
    7 Posts 3 Posters 1.1k Views 3 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M Offline
      MathijsK
      last edited by

      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

      M 1 Reply Last reply Reply Quote 1
      • M Offline
        mdima @MathijsK
        last edited by mdima

        @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

        M 1 Reply Last reply Reply Quote 1
        • M Offline
          MathijsK @mdima
          last edited by

          @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!

          M jeffreynJ 2 Replies Last reply Reply Quote 1
          • M Offline
            mdima @MathijsK
            last edited by

            @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

            1 Reply Last reply Reply Quote 0
            • M Offline
              mdima
              last edited by

              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

              M 1 Reply Last reply Reply Quote 0
              • M Offline
                mdima @mdima
                last edited by

                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

                1 Reply Last reply Reply Quote 0
                • jeffreynJ Offline
                  jeffreyn @MathijsK
                  last edited by

                  @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.

                  1 Reply Last reply Reply Quote 1
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.