Bug #1206
closed
OpenVPN client is not Multi-WAN capable
0%
Description
After several day of trying every possible solution, I have to report that the built-in OpenVPN client is not multi-WAN capable. This is (very vaguely) described in the pfSense book for 1.2.x (11.3.3 Local Services and Multi-WAN). Because OpenVPN client is a local service, is cannot use policy based routing.
However, the book also states "We hope to offer the ability to policy route traffic initiated by the firewall in pfSense 2.0 to allow more flexibility."
Is there any work being done on that?
My final setup which proves above statement:
1) pfSense 2.0 BETA, multi-WAN.
2) verify that M-WAN is working by checking that the IP address changes everytime I refresh an online IP address checker
3) verify that failover is working by "pulling cables"
4) from a computer in the LAN, initiate OpenVPN (UDP) connection, verify that connection is up and internal gateway IP is pingable
5) verify failover of the OpenVPN connection by pulling cables, connection should be re-established within the specified OpenVPN ping timeout
6) set up the same OpenVPN connection on the pfSense box
7) watch it only use one WAN connection, no failover
Last thing I had tried was to set up a port forward in pfSense and have the internal OVPN client connect to this, but again it works from a client in the LAN, but not from within pfSense itself.
Updated by Jim Pingle about 13 years ago
- Status changed from New to Rejected
Out of the box, a single client instance will not fail from WAN1 to WAN2 when coming from pfSense itself. You can select the interface directly in the OpenVPN GUI (what it really meant by multi-wan capable) but it doesn't failover or balance.
You could make it failover by adding some advanced outbound NAT rule and floating rules (the details of which will be documented in the near future), some of which has been covered on the forum (And on Scott Ullrich on twitter, he went over how to set it up for tcp/udp port 53 for Unbound, the same process would work for udp/1194 for OpenVPN)
Either way, not really a bug, but a matter of configuration. If you start a thread in the forum you may find some guidance there.