IPsec EAP-TLS can't reach remote network

  • Hi,

    I have been following this doc to setup an IPsec tunnel with certificates authentication between a client from a 1st LAN to reach all machines from a 2nd LAN : https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/ikev2-with-eap-tls.html

    I'm using the Windows VPN client (7 & 10 to test) to connect to my IPsec tunnel and with a lot of issues I managed to connect to it.

    But when my VPN is up, I can't reach any distant machine through ping, ssh, or anything.

    My phase 2 is correctly redirecting to the right LAN network but the odd is that I correctly receive an adresse for my client from the configured pool in pfSense but no gateway is attributed as you can see : ab37a3f0-7cda-42bd-8a41-9b2298883920-image.png

    The 1st LAN (client) is -> the 2nd LAN (distant) is

    The Virtual IP pool is

    If anyone has a clue of what it's causing the issue I'd be very grateful !


  • I'm not an expert here, but you can tcpdump on your pfsense box to make sure the traffic you expect is getting there? And you've checked the logs to make sure your traffic isn't getting blocked by the firewall right?

    You can also ask your Windows PCs how they will route to a particular destination with Powershell, e.g.:

    Find-NetRoute -RemoteIPAddress "" | Select-Object ifIndex,DestinationPrefix,NextHop,RouteMetric -Last 1

  • Hi,

    I have found something very weird when I came back to my lab. As it sometimes do, my pfsense won't keep the right time no matter the NTP configuration so I have to reboot it after powering the virtual machine.

    But today juste before doing that, I checked my tunnel on the W10 ( machine and this time I managed to ping machines in my .1.0 LAN and could see traffic in my firewall log.

    Then I've reboot my pfSense to refresh the time & date and now it's not working as before without any changes...

    Thanks for you reply, that's the result of your command : c320f07c-daf9-41d1-a8d2-b14599ed8fd5-image.png
    So same thing as my ipconfig command result

  • I have found in my IPsec logs that i have a DPD error, but I can't see where it's coming from or how to solve this


  • Tbh I don't see any DPD error there, they're just standard log messages. I don't see anything that looks related to the issue you're having.

    I'm not sure I can suggest anything useful here, but if I understand your setup looks something like:

    client <-> IPSEC <->pfSense <-> LAN

    And that LAN is directly connected to your pfSense box?

    What phase 2 network did you assign?

    How big is the subnet? /24? Is it definitely not used or overlapping with anything else the pfSense box can reach? I understand overlapping networks cause all sorts of problems in IPSEC.

    Also, I notice in your screenshot, your local Ethernet subnet mask is which is a /22, but you said it was a /24, which should be I'm not sure if that's relevant.

    FWIW, I don't get a gateway on my IPSEC interface either, seems normal.

  • You may find setting some of the IPSEC services to the diag log level as described here:


    From what I understand, your tunnel is coming up, but you can't reach anything connected to the remote pfSense networks once connected. It's hard to say what that could be, since it worked briefly and then stopped after a reboot. Are you pinging by IP or hostname?

  • Hi,

    Alright I thought it a DPD error my bad then.

    Yes my setup is exactly this one. Yes all my LANs are directly connected to my pfSense.

    The network assigned is my Phase 2 is my LAN (called LANSERVEURS as you can see) 4ef6f953-cf36-46c4-a21b-0d54dbed550c-image.png

    It is indeed a /24 network but also my only network using 10.10.x.x so no risk of overlapping anything other subnet.

    Yes my bad, both LANs are actually in /22 so having a .252, I've wrote to fast this information sorry. But everything is correct in the configuration.

    Yes it exactly do that. And sometimes with no reason my tunnel is fully functionnal for a few minutes with traffic on IPsec interface logs(ping, acces https web console on distant machines, etc)

  • Are you attempting to reach your hosts by IP or hostname?

    Also, I notice that would actually include anything between and wouldn't be a separate network. Do you have anything else using

    Can you tcpdump on pfsense while pinging from your VPN client to see where traffic gets to? Example:

    tcpdump -i enc0 src
    tcpdump -i <name of interface> src

  • By IP only for now

    Yes it does include that range, though I don't have anything using My first network starts at

    Nothing is shown on the tcpdump. As I could see on my firewall traffic, there is nothing after the tunnel connection to my interface (port 500). No sign of ICMP traffic

  • So can you see traffic actually hitting your IPSEC enc0 interface on the pfSense end at all or nothing?

    Can you ping an IP on the pfSense box?

    The Windows IPSEC client ignores static routes sent by a VPN gateway. Did you set the VPN connection on your Windows client to 'use default gateway on remote network'?:

    • Open Network and Internet Settings on the client PC
    • Click on the VPN tab on the left
    • Click Change adapter options on the right hand side of the VPN tab
    • Find your VPN connection, right click it and click Properties
    • On the Networking tab, select IPv4 and click properties, then Advanced
    • Tick Use default gateway on remote network
    • Click OK

  • There are 2 scenarios :

    • First one, is that I see only the traffic of the connection from the client to my tunnel interface, the tunnel is up but no traffic is seen after from the tunnel IP pool (as it was not up).

    • Second one, the tunnel goes up and everything works fine BUT it last only for a few minutes (sometimes randomly goes back up again and same thing)

    For your questions :

    • Yes I do see the IPsec traffic connection :d92cc15c-9bdd-407c-8a36-8958cd5a4521-image.png

    • You mean ping the client or remote IP from the pfSense ? In both cases I the pfSense can reach everything.

    • Yes I have noticed this parameter before and I already checked it. I first thought it was coming from the VPN gateway too.

    But I just noticed that the default gateway of the pfSense is my NAT gateway (my all lab is behind a NAT), so for my client using this gateway won't be any use. I don't know if i'm clear enough or a diagram of my architecture is needed.

  • Anyone ? :/

  • I'm out of ideas to be honest. If you're running the latest pfSense and the VPN is coming up but sometimes no traffic is passing, sometimes it is then I'd be inclined to think it's not pfSense but an external factor, so what's different on the client and on pfSense between when it works and when it doesn't?

    Is some other VPN up? Are you using wifi instead of wired? Can you access the Internet when the VPN is up? Is something else different? Have you look at the Windows Event Viewer and the pfSense logs in both scenarios?

    I meant from the client, can you ping interfaces on the destination pfsense box, other than the IPSEC interface? For example can you ping the pfsense interface that is connected to the LAN that you're trying to reach? What about other interfaces on the pfsense box?

    You're right, I don't really understand what you meant in the last sentence about the NAT gateway. A diagram may help me understand, but as I said, I'm not sure how much more I can help diagnose the problem.

  • @ads76 I also think it's an external factor, like the Windows client but nothing in the Event viewer logs appart the connection setting up.

    I don't have another VPN no. It's a virtual lab built on an ESXi so I'd say it's wired-like. No I can't while it's up. pfSense logs only show this (as shown before) : 851e0d78-6902-4387-8ef5-b0234e85e77d-image.png

    When the tunnel is up I cannot access or ping anything outside the LAN where the client is and the WAN interface ( - tunnel).

    We don't need to bother about the NAT gateway it's irrelevant sorry it's juste the default gateway of my pfsense to go outside of my lab.

Log in to reply