pfSense refreshes everything when an ovpn interface changes its IP



  • Hi,

    equipment: pfSense custom built router

    ovpn interfaces: 2 clients in group #1 (both Tier 1), 2 clients in group #2 (1 Tier 1, 1 Tier 2)

    problem: Frequent disconnections. All gateways appear in green color and seem to work but no connection. The logs show 2 main things - sometimes a TLS handshake error, probably due to UDP instability, sometimes (that's the bigger issue I think) pfSense detects an IP change of one of the ovpn interfaces and refreshes some things in order to reconnect, killing the Internet connection in the process, instead of just simply use the other Tier 1 client in the same group.

    Anyway here's the log screenshots:
    In this one, check the high latency and 20% loss warning/alarm of the WAN connection itself. Perhaps that's the issue, since pfSense will abandon such a connection (configurable though):
    Screen Shot 2020-02-11 at 11.18.08.png

    Screen Shot 2020-02-11 at 10.58.52.png

    Screen Shot 2020-02-11 at 10.41.38.png

    Screen Shot 2020-02-11 at 8.39.04.png

    Screen Shot 2020-02-11 at 8.38.49.png

    Screen Shot 2020-02-11 at 8.36.42.png

    Screen Shot 2020-02-11 at 8.36.26.png

    Screen Shot 2020-02-11 at 8.36.06.png

    Thank you,



  • Without reading all the logs, a wild guess:

    Is the dpinger pinging something INSIDE the VPN tunnel?

    Because when the VPN tunnel then goes down, it assumes that the outer connection is down, because that's what it has to take care of, and then just kills it.

    Cu



  • @Grimeton It pings the 10.8.x.x virtual IP address (I think, reading the logs) it receives from the remote VPN server which is wrong to even try and ping, right?

    But what about the WAN_PPPOE loss and high latency there?

    NordVPN support team suggested to try only one vpn client active and also TCP but I wanna solve it and not bypass the issue.



  • As far as I get it, again not read all the logs, dpinger is responsible to check if pppoe is up and running but it pings something INSIDE the VPN tunnel.

    So when the VPN tunnel goes down it sees a high loss of packets and does its job. The log refers to PPPoE because the dpinger belongs to PPPoE.

    You can let dpinger of pppoe ping 127.0.0.1 and never experience any downtime. It's important that dpinger pings something that is on the other end of the connection it is responsible for without having additional layers of routing/bridging going on.



  • @Grimeton So how do I make dpinger ping the WAN connection without going through the VPN (if this is what you meant)? Simple as adding a firewall rule/policy route?



  • Give it an IP-address that is going over the connection directly (e.g. the gateway on the other side, which should be used anyway).



  • @Grimeton Ok...sorry for the newb question, but how do I "Give it an IP-address" ? :)
    Basically what I'm trying to ask is: how do I tell the dpinger what to ping or what to do?



  • DPINGER is part of the gateway configuration. So first you RTFM.

    If you still don't know what to do afterwards you go to System/Routing/Gateways and edit the corresponding gateway. There you can add a Monitor IP and/or disable dpinger completely.

    Cu



  • @Grimeton It seems to monitor the correct address of my WAN. Did you mean add the actual VPN server's IP as a monitor IP for the VPN gateways?

    Also, just had another disconnection and the only new lines in the logs are these:
    Screen Shot 2020-02-11 at 13.02.18.png

    Screen Shot 2020-02-11 at 13.11.01.png

    The WAN gateway is always green and ok so the problem is probably that the dpinger pings the internal virtual IP of the VPN (10.8.x.x), instead of its server's actual IP, right?


Log in to reply