@daddygo Here some graphs/data from both 2.5.2 and 2.4.5. When comparing the graphs/data, I get the impression that 2.4.5 is having more packet loss than 2.5.2. Though I am experiencing the issues with 2.5.2...
Update: it seems that when PPPOE goes down, OpenVPN service start listening on an ip alias of my WAN interface and not on the main address.
After the service restart, it correctly goes listening on the main ip address.
@viragomann I tried disabling the port-forward rule but the connection didn't drop at all. Maybe I need to kill the states on the firewall but can't do that during production hours without disruption. I haven't actually disconnected the primary WAN either. I suppose I could try that after hours for a real test. I'm adding 2FA to our VPN connections so this is the perfect time to make the connections more robust with failover as well.
@petr I am having the same issue. I also have an OpenVPN client that is using the failover WAN interface. My failover WAN is a 4G modem that I pay for the data I use on, so I want to limit the devices that can use this interface. All the rules seem to work fine except that the VPN connects and devices that use that VPN can still access the internet and tank my data plan. Did you ever find a solution to this?
@viragomann , first, thanks again for your help and support on this.
for all and benefit of the forum :
Took me a long time to figure out , as there was several issues ,
I bypass all tests done going to outcome
1 - my hardware was not strong enough : changes where not applied properly all the time - > this is why I had non consistent behaviors ( I set manually the "Firewall Maximum Table Entries", so apparently no error, but all changes were not applied)
Solution to this 1st point : ordered a new box ( that's why it took some time to get it from china ... )
2 - I had duplicate ranges in my IP's ( the one assigned by VPN was another one as well on another link of my FW )
Having solved these 2, I have the VPN connection created, stable with a GW defined.
In the meantime, I have in the new box a wifi connection, that I 'm gonna use as fail-over solution. I will be able to make tests unlink from the VPN, and see if now I encounter the same problems
It seems like the vpn is not allowing icmp or telnet to route.
Use Packet Capture or Wireshark to see how far the packets are getting and whether you're getting a response. For example, you could run Packet Capture on the pfsense end of the VPN to see if the packets get that far. However, I can assure you that OpenVPN passes pings as I have done that many times. If your pings aren't getting through, then you likely have some rule issue.
or, more specific : one or more items in this list (marked with a red cross ) :
doesn't correspond with the OPVN client file (OpenVPN client settings).
The server disagrees with the client.
The servers throws out an 'error' : TLS Error: TLS handshake failed.
edit : and before you think : "why does this happen to me ?"
The answer is a solid : "go talk with the admin".
We all see this error ones in a while. Rarely, it works 'right away'.
( at least, it never did for me ;) )
What I normally do :
I compare the config file of the server and the client. These are small text files. Easy to read.
This is the old fashioned way of making to devices talk to each other : compare their settings on both sides - using a paper and pencil.
Btw : also compare your OpenVPN server version number - and the OpenVPN client version number. If they differ, you also have to read the OpenVPN doc of both version, that is, the details of all the settings used. You're good for a visit at openvpn.org - the section 'manual'.
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.