OpenVPN site-to-site multi-WAN
-
"Default Gateway Switching" allows the internals of the pfSense box to find a fail over path to the internet - e.g. GUI functions that go to the internet to look something up (updates availability, available package list) or ordinary "ping" from the command line.
The code does check that it is not about to switch the default gateway to LAN. But I guess it has to just pick another interface that is up and hope it leads somewhere useful. It seems to work fine on simple configs, like having 1 LAN and 2 WAN.
I tried to find a way to add rules to feed this stuff into a gateway group - e.g. a floating rule feeding anything from 127.0.0.1, WAN Address into a gateway group. But no joy, I guess this local traffic never made it into the pf system to get filtered and policy routed? Or did I miss something in my setups?
Is there a way to get the internal traffic generated in the box to feed into a gateway group and be policy routed? -
Is there a way to get the internal traffic generated in the box to feed into a gateway group and be policy routed?
yes, with quick floating rules
-
Phil's way seems to be working very well or me. I've done various combinations of unplugging gateways at each end, and traffic seems to flow just fine no matter what. It also seems to automatically go back to the main gateway when it is plugged back in. I guess my simple configuration (pretty much identical to Phil's in every way) doesn't do anything to confound the limitations of the default gateway switching option.
On 2.1 you can (once all the code is finished) select a gateway group for the client (and/or server's) "Interface" and it can failover that way.
I'm very much looking forward to that. How long do you think it will be before that's available Jimp?
-
So, maybe it's a mistaken half-newbie intuition but–
Why not port forward the various OpenVPN target ports on all the variously available WAN interfaces to 'localhost', have PF's openvpn listen only on 'localhost' using the various ports for the various client types without regard to route? Be sure the option that routes traffic out the port it came in on is checked, and --- viola? Yes? No?
-
On 2.1 you can (once all the code is finished) select a gateway group for the client (and/or server's) "Interface" and it can failover that way.
So if I'm not mistaken, wouldn't that completely eliminate the need for OSPF? I'm trying really hard to avoid using beta packages in this particular production environment because so much is at stake. Not to mention I'm never quite sure if I've got OSPF configured correctly. It's very new to me.
Why not port forward the various OpenVPN target ports on all the variously available WAN interfaces to 'localhost', have PF's openvpn listen only on 'localhost' using the various ports for the various client types without regard to route? Be sure the option that routes traffic out the port it came in on is checked, and –- viola? Yes? No?
That's basically what Phil's done. Traffic on the OVPN ports was NAT'd to the LAN IP and then listening is done on the LAN interface without regard to route. Although, I'm not sure what "option that routes traffic out the port it came in on" you're referring to.
-
So if I'm not mistaken, wouldn't that completely eliminate the need for OSPF? I'm trying really hard to avoid using beta packages in this particular production environment because so much is at stake. Not to mention I'm never quite sure if I've got OSPF configured correctly. It's very new to me.
In my environment, we have a group of half a dozen main offices that have a full-mesh of OpenVPN links between them all. So from any of these offices, any other office can be reached directly across a single OpenVPN link. If your network is manageably small like that, then you can have the full-mesh of OpenVPN links. By entering local and remote network CIDR on the OpenVPN links you get a complete routing table for your private intranet - no need for OSPF.
Then I add a small branch office. It sends 99% of its data to 1 partner office, so I just make 1 OpenVPN link to that office. But so that it can also reach other offices occasionally, I have to add:
a) "route" commands in the advanced section on the branch office client, telling it that the OpenVPN link is the way to a bunch of other office subnets also.
b) at each other office, saying that the way to "branch office" is via "partner office".
Once this happens more than a couple of times, you start to think it would be nice to run something like OSPF - then the routes to parts of the private network that are not full-meshed can be learnt automatically. It all depends how complicated your private network topology is and how often it changes. -
Hi everyone,
I am just trying to follow the post and I am not too much technical in terms of all this VPN and Failover. In my case, I have the following locations and desired configuration;
Head Office- Lan = 10.60.1.0/24
- DMZ = 192.168.2.0/24
- Wan 1 = xxx.xxx.xxx.xxx/30 (Data Link without Internet)
- Wan 2 = xxx.xxx.xxx.xxx/30 (Data Link without Internet)
Branch 1 - Lan = 10.60.2.0/24
- Wan 1 = xxx.xxx.xxx.xxx/30 (Data Link without Internet)
- Wan 2 = xxx.xxx.xxx.xxx/30 (Data Link without Internet)
Branch 2 - (Newly Upcoming) - Lan = 10.60.3.0/24
- Wan 1 = xxx.xxx.xxx.xxx/30 (Data Link without Internet)
- Wan 2 = xxx.xxx.xxx.xxx/30 (Data Link without Internet)
Normally, with a Single WAN link HO->Br-1 is connected over VPN and everything is fine and working. I wanted to follow the post to configure (Automatic Failover on MultiSite with Dual Wan over OpenVPN) Automatic Failover for VPN on both end i-e Head Office and Branch plus same for the newly upcoming branches.
My questions are;
- Is that post and configuration workable for more than 1 Client?
- How do I configure the next coming Branches? and What will be the VPN Configuration of Newly coming branches?
Thanking you in advance for any coming help!!
-
Since this post, 2.1-BETA1 has added:
a) the ability to a list of networks in the Local Networks and Remote Networks fields of OpenVPN Server/Client. You do not need to put "route" or "push route" statements in the advanced box any more.
b) OpenVPN Client can use a Gateway Group instead of a particular interface - so no need to bother with the default gateway switching business, or other trickery to convince the client thta it has multiple ways out to the internet.
c) OpenVPN Server can listen on a Gateway Group - I haven't used that, I still port forward to LAN and make my server listen on LAN. But the Gateway Group listen should allow you to have the server listening just on the highest-priority interface in the Gateway Group. That way the server should fail-back when the high-priority WAN interface comes back up after a failure.As I installed more pfSense at remote offices I ended up with lots of OpenVPN servers at my main offices - call them M1 and M2 - every branch office had 2 clients, connecting to M1 and M2. After 5 or 6 of these I decided to change to Peer-to-Peer SSL/TLS - that allows me to have just 1 server at M1 and 1 server at M2. With Client-specific overrides I can tell the server what remote office subnet is at the end of which connection. The routing failover principles apply just the same to the PSK or SSL/TLS security method.
You choose if you want to make a new PSK server to listen for each branch office, or 1 SSL/TLS server to listen for all offices.
This post has more interesting discussion: http://forum.pfsense.org/index.php/topic,59656.0.html
-
Hi Phil,
One more time, need a little help. With the said Guide, I followed the exact procedure. VPN established and net-to-net + DMZ all are working fine. But when I dis-connected WAN to test Failover to OPT-1, it's not establishing connection. OpenVPN Logs on server has following error lines:
Feb 22 03:13:19
openvpn[18246]: Authenticate/Decrypt packet error: packet HMAC authentication failedFeb 22 03:13:21
openvpn[18246]: Authenticate/Decrypt packet error: packet HMAC authentication failedFeb 22 03:13:23
openvpn[18246]: Authenticate/Decrypt packet error: packet HMAC authentication failedFeb 22 03:13:31
openvpn[18246]: Authenticate/Decrypt packet error: packet HMAC authentication failedFeb 22 03:13:32
openvpn[18246]: Authenticate/Decrypt packet error: packet HMAC authentication failedFeb 22 03:13:43
openvpn[18246]: Authenticate/Decrypt packet error: packet HMAC authentication failedFeb 22 03:13:43
openvpn[18246]: Authenticate/Decrypt packet error: packet HMAC authentication failedand OpenVPN logs on Client has:
Mar 13 10:48:36 openvpn[12597]: Inactivity timeout (–ping-restart), restarting
Mar 13 10:48:36 openvpn[12597]: SIGUSR1[soft,ping-restart] received, process restarting
Mar 13 10:48:38 openvpn[12597]: NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
Mar 13 10:48:38 openvpn[12597]: Re-using pre-shared static key
Mar 13 10:48:38 openvpn[12597]: Preserving previous TUN/TAP instance: ovpnc3
Mar 13 10:48:38 openvpn[12597]: UDPv4 link local (bound): [AF_INET]10.60.3.21
Mar 13 10:48:38 openvpn[12597]: UDPv4 link remote: [AF_INET]192.168.31.34:1194Any Idea/Help appreciated.
-
The server errors are really old and I do not think related to your current problem, so I will ignore them.
It seems that the client is simply not getting through to the server at all.Mar 13 10:48:38 openvpn[12597]: UDPv4 link local (bound): [AF_INET]10.60.3.21 Mar 13 10:48:38 openvpn[12597]: UDPv4 link remote: [AF_INET]192.168.31.34:1194
From the above, the client is correctly bound to a LAN IP at Branch2.
For some reason it thinks it should connect to the server on 192.168.31.34 - which is a private IP. Unless you have setup a completely private test environment, then that is not a valid address of the server.
If the client is setup correctly, with an extra "remote" statement in the advanced box, then the client log should cycle around about every minute trying
"UDPv4 link remote: [AF_INET] n.n.n.n:1194" and
"UDPv4 link remote: [AF_INET] m.m.m.m:1194"
where n.n.n.n and m.m.m.m are the 2 WAN IPs at the server end.
Both those server WAN IPs should be port-forwarded to LAN on the server end, where the server should be listening.
What did I misunderstand about your setup?