OpenVPN Multiple WAN Failover Question
-
Hi all,
I have a quick question how to properly configure OpenVPN in a multiple WAN scenario. Let's assume I have two WAN connections (e.g. WAN1 and WAN2) configured in a failover gateway group. WAN1 is Tier1 and WAN2 is Tier2. I understand that I can choose the failover gateway group for the interface under the OpenVPN server setup, and that the OpenVPN server should fail over to (i.e. be bound to) WAN2 if the WAN1 connection goes down. In terms of firewall rules, for this to work properly I assume I have to allow inbound traffic to OpenVPN on both WAN1 and WAN2 interfaces. My question is, what happens if someone tries to connect to the VPN port on WAN2 when the OpenVPN server is only bound to WAN1? Does having an open port like that (with no service listening) pose a security risk? If yes, is there a better way to set this up to have proper multiple WAN failover functionality with an OpenVPN server?
Thanks in advance for your help, I really appreciate it.
-
@tman222 said in OpenVPN Multiple WAN Failover Question:
My question is, what happens if someone tries to connect to the VPN port on WAN2 when the OpenVPN server is only bound to WAN1? Does having an open port like that (with no service listening) pose a security risk?
No, a port without a service listening on it I'd not considered as open.
Another approach is to set the OpenVPN server listening on localhost and forward the OpenVPN packets from both WANs to it.
-
@viragomann said in OpenVPN Multiple WAN Failover Question:
@tman222 said in OpenVPN Multiple WAN Failover Question:
My question is, what happens if someone tries to connect to the VPN port on WAN2 when the OpenVPN server is only bound to WAN1? Does having an open port like that (with no service listening) pose a security risk?
No, a port without a service listening on it I'd not considered as open.
Another approach is to set the OpenVPN server listening on localhost and forward the OpenVPN packets from both WANs to it.
Thanks @viragomann for the reply. I read about the localhost approach as well in the docs:
https://docs.netgate.com/pfsense/en/latest/multiwan/openvpn.html
Is one way preferred over the other, i.e. binding OpenVPN to localhost and forwarding both WAN connections to it vs. just using the failover gateway group as the OpenVPN interface? Is one approach more flexible or more secure than the other? I suppose one thing I can think of that may favor the localhost approach is if WAN1 does go down and things don't properly fail over to WAN2, VPN access would still be available on WAN2 regardless.
Thanks again.
-
@tman222
This depends on your use case and on your environment.From the point of security I don't think that there are differences, but there might be some others:
Gateway group
- different trigger methods for failover like member down, high latency and packets loss.
in the gateway advanced settings you can additionally adjust some thresholds. - server influences, which interface to use
Forwarding
- traffic is simply forwarded constantly
- the client decides, which WAN to connect to
- different trigger methods for failover like member down, high latency and packets loss.
-
@viragomann said in OpenVPN Multiple WAN Failover Question:
@tman222
This depends on your use case and on your environment.From the point of security I don't think that there are differences, but there might be some others:
Gateway group
- different trigger methods for failover like member down, high latency and packets loss.
in the gateway advanced settings you can additionally adjust some thresholds. - server influences, which interface to use
Forwarding
- traffic is simply forwarded constantly
- the client decides, which WAN to connect to
Thanks @viragomann - that's very helpful. I'll experiment a bit to see how things work using the gateway group failover method. In this particular case WAN2 is just a cellular back up connection and should really only be used if the primary WAN1 connection (fiber) fails. That being said, if I experience issues with the failover not working properly, I'll probably just switch over to the forwarding method instead. Thanks again for your help.
- different trigger methods for failover like member down, high latency and packets loss.
-
@viragomann said in OpenVPN Multiple WAN Failover Question:
Another approach is to set the OpenVPN server listening on localhost and forward the OpenVPN packets from both WANs to it.
This is exactly how I have my VPN Server & it works well. My client simply has both DDNS names as the VPN address. The client will try the first one, and if that fails try the other. Same process works if one WAN is fails on PfSense, My tunnelblick client will also retry the connections if the failure happens while I'm connected.
-
@pwood999 said in OpenVPN Multiple WAN Failover Question:
@viragomann said in OpenVPN Multiple WAN Failover Question:
Another approach is to set the OpenVPN server listening on localhost and forward the OpenVPN packets from both WANs to it.
This is exactly how I have my VPN Server & it works well. My client simply has both DDNS names as the VPN address. The client will try the first one, and if that fails try the other. Same process works if one WAN is fails on PfSense, My tunnelblick client will also retry the connections if the failure happens while I'm connected.
Hi @pwood999 - thanks for and responding and confirming that this method works well. If you don't mind me asking, what do you use for the authentication backend for OpenVPN? Is it the local DB, FreeRADIUS, or something else? The reason I ask is that I'm having trouble getting the port forward method to working properly using FreeRADIUS for authentication - even I connect via WAN2, traffic still flows back out WAN1 leading to asymmetric routing issues:
https://forum.netgate.com/topic/186620/openvpn-multiple-wan-asymmetric-routing-issue
Thanks in advance.
-
@tman222 Just the local DB.
-
@tman222
I don't expect, that any Radius traffic going out of pfSense. I don't use it, but as I understand it, it's just a local authentication server.So if the reply-to tags are applied properly to the VPN connection, I'd expect it to work.