Windows Roadwarriors and PFsense 2.2.3+ IPsec VPN not working anymore



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



  • 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…






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



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



  • IPsec for road warriors in PfSense using the ShrewSoft VPN client

    Would this perhaps be better for the Windows clients?



  • 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?



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



  • 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?



  • 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…



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



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



  • 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