RTT values for VPN gateways unrealistically low



  • I recently setup an OpenVPN client connection to AirVPN. The resulting VPN gateway shows an RTT time of 0.2 - 0.4 ms, which is unrealistically low. Even my ISP's gateway registers 2-4 ms.

    I searched the AirVPN forums and came across the following posts:

    https://airvpn.org/topic/28793-monitor-ip/

    "by default pfsense will monitor my end of the VPN, not the gateway. (but, it monitors the gateway my ISP WAN properly) I have to manually change the monitor IP. It's a good question and something people bug pfsense devs about often." - go558a83nk

    "Yes, that's how setup. RTT for that by default is always 0.1ms because it's pinging my VPN internal IP, not the gateway." - go558a83nk

    These posts suggests that pfSense monitors the near side of the VPN connection, which if true, provides next-to-useless information. I certainly hope my pfSense box can recognize itself in less than 0.2 ms.

    Does anyone have any comments here? Is something configured wrong or is this a bug in pfSense? Thanks for your time!



  • I can tell you in the gateway monitor box on the dashboard, my RTT is for the remote location

    78ms for my USA VPN and 8ms for my EU VPN which is right given I am in the UK.

    You can adjust the monitoring ip in the gateways -> routing section.



  • That is interesting. One poster on the AirVPN thread reported reasonable RTT values, which left the rest flummoxed as to why they were not seeing similar behavior on their pfSense installations.

    What address do you put in the Monitor IP field? For my settings, the Gateway field lists "dynamic", which is grayed out. When I go to Status --> Gateways, the Monitor IP is automatically assigned the same IP address as the Gateway, which is pushed from AirVPN. If I change the Monitor IP to the IP address of the actual AirVPN server, pfSense becomes unresponsive and will not let me return to the dashboard or Status --> Gateways.



  • for my VPN's I havent put anything in there, its using the default, which the default is the gateway ip.

    But if the default doesnt work for you then you can put whatever ip in there you want.



  • Coming back to this I see what you mean, I expect I previously manually fixed it and forgot about it.

    I consider what I am seeing on my unit a bug but I dont know how to approach reporting it, so nothing will happen on my end of r awhile.

    But here is a summary and it explains the problem you reported.

    So on my network I have my fixed line default internet connection which is IPoE (dhcp), this is dual stacked so one gateway for ipv4 and another gateway for ipv6. This side of things work as expected no issues.

    Where things get complicated is my VPN's and my backup 4G internet connection. Once these are configured, the gateway part of pfSense starts misbehaving.

    So e.g. pfSense has a habit of automatically adding a gateway for a interface. When I configure my VPN's it automatically creates a gateway or two gateways depending on the gateway option configured in the VPN client section, notably you cannot choose to have no gateway auto created.

    The gateway that is auto created, cannot be renamed, and it cannot be deleted, which is odd, as this unable to delete feature, is only present on the newest auto created gateway, all older auto created gateways have the trash button as a clickable option. The default gateway actually does as you said use the local VPN ip as its default ping ip for the dpinger. I am not sure if pfSense has always behaved in this manner or it changed in recent versions, I may have simply just always reconfigured it and forgot about it.

    My specific problem has arisen due to problems with my backup 4G gateway configuration. I expect I would have been ok if I just had my normal WAN and VPN gateways configured.

    So basically I have a failover gateway group configured, which consists of my default WAN gateway and my 4G gateway. When a gateway is in a gateway group it cannot be disabled or deleted. However if I do not delete the mobile phone interface and reboot pfSense without the mobile phone connected, then there is no ue0 device, and pfSense will completely freak out, and ask me to reconfigure "ALL" interfaces on the CLI during the boot process, obviously this is catastrophic.

    The workaround to this problem is to manually delete the OPT interface assigned to ue0, when disconnecting the phone from the device. Meaning this interface is never active on reboots when the phone is disconnected.

    This kind of works ok as long as no new gateways are added whilst ue0 OPT device is non existant, so the gateway for the 4G will stay configured, and just in a down state and basically the pfSense unit just carries on working as intended. If the phone is reconnected, I add the OPT device again, and as long as the OPT device has the same numbering as when it was removed, the gateway picks it up and will function in a online state.

    But if I add a new interface whilst the phone is disconnected such as a VPN interface, the VPN will auto create its gateway, it then notices the 4G gateway which has its interface missing, and assigns the 4G gateway to the VPN effectively completely breaking my configuration. This is an example of when auto configuring can just breakdown completely and manual configuring can be superior.

    At this point I can e.g. manually add a new gateway for the VPN, and it will function, but I would be left with the 4G gateway assigned to the VPN interface, unable to reassign it to the phone interface because its disconnected, and ultimately to fix it the phone has to be reconnected so the correct device can be reassigned to the 4G gateway.

    When I did this just now, pfSense for whatever reason, decided to create a second ipv4 gateway for my VPN that is a clone of a already working gateway and has the trash/delete button not visible for this cloned gateway, if I disable the gateway, the button appears, I click it, but it auto instantly recreates the cloned gateway, so at best I can disable this cloned gateway, but not delete it, so its a visual mess. This gateway has the problem you described where it monitoring the VPN ip assigned to the pfSense side of the VPN connection not the remote ip. Which is what made me come back here to update my feedback.

    I dont remember having these weird gateway issues when I originally set this up on pfSense 2.3.x which has me kind of thinking a change made since then has caused these duplicated gateway issues, but I dont know if the ip setup for dpinger was always like this or not, that to me is a very minor issues as the monitoring ip can be easily overriden on the gateway.

    As to my gateway mess problem, the fix is clearly not easy, hence me not sure how to report the problem, one such possible solution is to allow someone to add a VPN client, without any gateway been auto created, leaving that as a manual process, but that wouldnt resolve the 4G interface/gateway problem. Ideally I would like to be able to keep my 4G interface configured with the phone disconnected, and on reboot's pfSense doesnt freak out.



  • I cannot edit my above post, so apologies for replying twice.

    I can confirm my older VPN's have the correct gateway ip configured, with no monitoring ip override, but the auto configured gateway for the newer vpn I configured, has the local ip configured instead of the remote ip, this does indeed suggest the behaviour has changed in newer versions of pfSense, as these vpn's are configured the same, they all openvpn, the only difference is when they were added to the unit.

    I also found my notes I written when I added my older VPN's and its like a guide I written to so I knew how to repeat the process and I can confirm I had to manually add the gateways.

    Gateways can be still manually created for VPN's, but they are then duplicates since the auto created gateway cannot be persistently deleted. The manually created gateways I can confirm will use the correct gateway ip by default as I simply manually entered the ip, whilst on the auto gateways, the ip box is ghosted out with the word dynamic in place. So to me this is a bug in the change that was made to the VPN client section to auto create gateways.0_1546355565854_brokengateways.png

    In short I probably am not that bothered about the ue0 issue, I dont add new VPN's often, and its not a huge deal for me to recreate the interface when using the 4G on pfSense, but I will probably submit a request for an option to disable the auto gateway creation for VPN client's as I see that as a nuisance., for me the old manual process is better. As you can also see in the screenshot not only is the gateway ip correct but I can name the gateway as I see fit.



  • @chrcoluk

    I have discovered a work-around that seems to work. AirVPN assigns my pfSense firewall an IP address in the 10.0.0.0/8 CIDR based on the server pfSense is connected to. For example, I may get an address like 10.52.68.42. If I change the last digit to 1 (i.e., 10.52.68.1), and insert the result IP address into the Monitor IP field of the gateway settings, I get proper ping times. I believe the X.X.X.1 effectively specifies the internal address of AirVPN's respective gateway.

    Unfortunately, this work-around is not a complete solution to my problem. In my OpenVPN configuration, I actually have four AirVPN server connections active. A first pair corresponds to one physical location (e.g., New York, NY) and a second pair corresponds to another physical location (e.g., Newark, NJ). I choose the physical locations based on their corresponding servers ping times, namely, the first pair has the lowest ping times and the second pair has the next lowest ping times. pfSense is configured to load balance the servers within each pair, and the higher latency pair serves as a failover to the lower latency pair.

    If try to set the Monitor IP of each respective gateway to X.X.X.1, I get proper latency values for only one (and sometimes two) AirVPN servers. The others are listed as offline. So the work-around seems to function okay for one active server, but with more than one, pfSense seems to have issues.