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

    Windows Roadwarriors and PFsense 2.2.3+ IPsec VPN not working anymore

    Scheduled Pinned Locked Moved
    IPsec
    4
    12
    3.2k
    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.
    • D
      djheadcrash
      last edited by

      Hey guys,

      Since the last update 2.2.3, I am unable to get my IPsec IKEv2 VPN properly working again.

      My Setup:

      • 2 Roadwarriors on Windows 8.1 Professional and Windows Phone 8.1 GDR 2
      • Certs for VPN are installed, authentication by Username / Password
      • PFsense with green and red interface

      Network setup:
      PFsense: 192.168.1.1
      Subnet: 192.168.1.1/16
      IPsec Address Pool: 192.168.17.1/30

      I can successfully connect to the VPN, obtaining an IP from the pool that I've defined in PFsense but the only device
      that I can communicate by VPN in my LAN is PFsense itself. All other network devices are unaccessible.

      Before this update, everything was working correctly. I was able to tunnel both my LAN and WAN communication through IPsec.

      Things I did so far to recover my VPN:

      • Several times restarted PFsense / Strongswan / DHCP…
      • Manually setting the route for all network traffic to PFsense (ROUTE ADD 0.0.0.0/0 192.168.1.1)
      • Completely moving the LAN from 192.168.1.1/24 to 10.0.0.1/8 and back (to check if this makes any difference...)
      • Updating to one of the latest development snapshots (2.2.4)

      I also checked the IPsec.conf in var/etc if there is something unusual but the configuration doesn't seem to me malformed.

      As I see, many of you are using IPsec in PFsense without any problems until now and I haven't made any configuration changes
      on my own.

      Moreover, I have even no idea anymore how to get the VPN again up & running, so I need your help...

      Update:
      When checking in Windows the ipconfig, I wonder about the default gateway 0.0.0.0:

      IPv4-Adresse  . . . . . . . . . . : 192.168.17.1
        Subnetzmaske  . . . . . . . . . . : 255.255.255.255
        Standardgateway . . . . . . . . . : 0.0.0.0

      Thanks in advance!

      1 Reply Last reply Reply Quote 0
      • D
        djheadcrash
        last edited by

        In this post, you'll find the strongswan.conf and ipsec.conf which has been created by PFsense.

        I am not able to figure out, why I only can communicate with PFsense while connected to the VPN…

        screenshot_ipsecconf.PNG
        screenshot_ipsecconf.PNG_thumb
        screenshot_strongswanconf.PNG
        screenshot_strongswanconf.PNG_thumb

        1 Reply Last reply Reply Quote 0
        • C
          cmb
          last edited by

          Windows tends to not like wrong network addresses. Looks like you have 192.168.1.1/24 configured in there somewhere, that should be 192.168.1.0/24.

          1 Reply Last reply Reply Quote 0
          • D
            djheadcrash
            last edited by

            I've changed this everywhere to 192.168.0.0/16…

            This changed the ipsec.conf tofollowing:

            leftsubnet = 192.168.0.0/16

            Anyway, no successful tunneling to LAN nor WAN. Only PFsense can be accessed as the only host... :-(
            I've even rebooted PFsense...

            1 Reply Last reply Reply Quote 0
            • ?
              Guest
              last edited by

              IPsec for road warriors in PfSense using the ShrewSoft VPN client

              Would this perhaps be better for the Windows clients?

              1 Reply Last reply Reply Quote 0
              • D
                djheadcrash
                last edited by

                Hi BlueKobold,

                I can try out if the ShrewSoft VPN client can handle it. Anyway, the Windows Phones will be not able to use the VPN anymore as there is only the Microsoft IKEv2 implementation out there.

                Honestly, I was already often thinking about moving to OpenVPN but it lacks a client implementation for the phones as well…

                If I could only understand what has been changed under the hood that my setup that worked until 2.2.2 totally fine is now broken...

                @All: Is there a way to downgrade PFsense back to 2.2.2 safely? Are there any big security issues concerning the WAN on that version?

                1 Reply Last reply Reply Quote 0
                • ?
                  Guest
                  last edited by

                  Honestly, I was already often thinking about moving to OpenVPN but it lacks a client implementation for the phones as well…

                  Yes this is really sad, I was really thinking about that one coder will be perhaps write a pfSense APP and/or
                  a OpenVPN APP with VPN capabilities to make things such that much easier.

                  @All: Is there a way to downgrade PFsense back to 2.2.2 safely? Are there any big security issues concerning the WAN on that version?

                  Fresh install 2.2.2 and then install the stored configuration backup, done.

                  1 Reply Last reply Reply Quote 0
                  • C
                    cmb
                    last edited by

                    Downgrading is extremely unlikely to change anything where you're on latest 2.2.4 already especially, and where IPsec itself is actually functioning fine. Troubleshoot the problem further. Run a constant ping to something on the LAN that isn't replying. Diag>Packet Capture, IPsec interface, for host enter IP you're pinging, click Start. Let it run for a handful of seconds or so and click Stop. See the traffic coming in there? If so, switch to LAN, otherwise same. Repeat the capture on LAN. See the traffic there?

                    1 Reply Last reply Reply Quote 0
                    • D
                      djheadcrash
                      last edited by

                      Hey cmb,

                      Thank you for giving me this essential hint for further troubleshooting.

                      In my LAN, I have a QNAP NAS which I decided to ping through the IPsec tunnel.

                      This is the capture of the IPsec interface:
                      23:44:27.447868 (authentic,confidential): SPI 0xcf63d8ef: IP 192.168.17.1 > 192.168.1.200: ICMP echo request, id 1, seq 49, length 40
                      23:44:32.043577 (authentic,confidential): SPI 0xcf63d8ef: IP 192.168.17.1 > 192.168.1.200: ICMP echo request, id 1, seq 50, length 40
                      23:44:32.292790 (authentic,confidential): SPI 0xcf63d8ef: IP 192.168.17.1.61466 > 192.168.1.200.8612: UDP, length 16
                      23:44:37.064449 (authentic,confidential): SPI 0xcf63d8ef: IP 192.168.17.1 > 192.168.1.200: ICMP echo request, id 1, seq 51, length 40
                      23:44:42.064908 (authentic,confidential): SPI 0xcf63d8ef: IP 192.168.17.1 > 192.168.1.200: ICMP echo request, id 1, seq 52, length 40

                      And finally, I repeated the ping while capturing the LAN interface:

                      23:45:35.397912 IP 192.168.17.1.63549 > 192.168.1.200.8612: UDP, length 16
                      23:45:35.398016 ARP, Request who-has 192.168.17.1 tell 192.168.1.200, length 46
                      23:45:35.683931 IP 192.168.17.1 > 192.168.1.200: ICMP echo request, id 1, seq 53, length 40
                      23:45:36.395202 ARP, Request who-has 192.168.17.1 tell 192.168.1.200, length 46
                      23:45:37.395207 ARP, Request who-has 192.168.17.1 tell 192.168.1.200, length 46
                      23:45:40.558908 IP 192.168.17.1 > 192.168.1.200: ICMP echo request, id 1, seq 54, length 40
                      23:45:40.559005 ARP, Request who-has 192.168.17.1 tell 192.168.1.200, length 46
                      23:45:41.555213 ARP, Request who-has 192.168.17.1 tell 192.168.1.200, length 46
                      23:45:42.555216 ARP, Request who-has 192.168.17.1 tell 192.168.1.200, length 46
                      23:45:45.558635 IP 192.168.17.1 > 192.168.1.200: ICMP echo request, id 1, seq 55, length 40
                      23:45:45.558735 ARP, Request who-has 192.168.17.1 tell 192.168.1.200, length 46
                      23:45:46.555222 ARP, Request who-has 192.168.17.1 tell 192.168.1.200, length 46
                      23:45:47.555228 ARP, Request who-has 192.168.17.1 tell 192.168.1.200, length 46
                      23:45:50.559209 IP 192.168.17.1 > 192.168.1.200: ICMP echo request, id 1, seq 56, length 40
                      23:45:50.559307 ARP, Request who-has 192.168.17.1 tell 192.168.1.200, length 46
                      23:45:51.555228 ARP, Request who-has 192.168.17.1 tell 192.168.1.200, length 46
                      23:45:52.555230 ARP, Request who-has 192.168.17.1 tell 192.168.1.200, length 46

                      I guess this proofs that at least the packets go through the tunnel and even move into the LAN.

                      Are the multiple ARP packets normal? It seems to me that they don't go back into the IPsec interface…

                      1 Reply Last reply Reply Quote 0
                      • C
                        cmb
                        last edited by

                        Good, that shows the exact issue. Your NAS has a wrong subnet mask, probably 255.255.0.0, so it thinks 192.168.17.1 is a local IP. It's not replying because nothing answers ARP for an off-subnet IP.

                        Fix the NAS's subnet mask, make sure its gateway is correct, and it'll reply back correctly.

                        1 Reply Last reply Reply Quote 0
                        • D
                          djheadcrash
                          last edited by

                          I modified the subnet mask and voila: All communication between LAN and IPsec worked instantly.

                          To get the WAN tunneled as well, I modified the Phase 2 to map 0.0.0.0/0.

                          Thank you for the right hints!!!

                          1 Reply Last reply Reply Quote 0
                          • D
                            D-Kun
                            last edited by

                            I have had the same issue with setting up IPsec IKEv1 tunnel (Roadwarriors/Remote mobile setup).
                            I just got parts of the LAN-NW working. Also testet yesterday 0.0.0.0/0 for WAN, but it was not successful. Was not able to think that setting this to LAN interface for Phase 2 will resolve this isseu!

                            Thanks guys!

                            –
                            greetz

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