Load balancing across 2 VPN instances
-
I was following https://www.techhelpguides.com/2017/06/12/ultimate-pfsense-openvpn-guide/ but did not succeed. I created 2 OpenVPN instances to the same provider, different locations.
They both have interfaces configured. They both have Gateways configured. A Group Gateway was created. I created NAT Outbound entries, but I am not sure that is correct and/or that all entries are in the correct order. I created a LAN rule using the Group Gateway. I am also using Unbound for DNS over TLS. I am not sure how to configure that for this configuration. The Newtok Interfaces are LAN and WAN. WAN in this case is a DHCP LAN between the AT&T modem and the router. The Outgoing Network Intrfaces is LAN only. I want to use the VPN provider's URL for their locations and get the IP (one of several possible) using DoT before the VPN is running. By using LAN, it goes out the WAN until the VPN is running, then all following DoT goes out the VPN. But that is for the single VPN case. It does not seem to bo compatible with this dual-VPN case.
NAT Outbound:
Firewall LAN Rules:
How can I get this working correctly?
How can I determine that it is working?
I certainly need help understanding NAT Outbound entries better.
Thanks. -
Yes, pilot error again. NAT Outbound entries are processed from top to bottom where the first match exits (skips remaining entries). The same happens for WAN and LAN rules; firstmatch wins. Not necessarily so for Floating Rules, it is selectable. When I first created a VPN server, I followed a standard process that duplicated all the standard NAT Outbound entries for the OpenVPN interface (an Interface that only appears for Firewall Rules and NAT). I guess these work for simple VPN set ups. Adding a VPN provider using a single access point required no change. Now, for load balancing using multi-VPN instances, no longer valid.
What I did:
Also need to adjust the LAN rule:
To let WANnet traffic (an AT&T modem LAN in my case) so I can access the device.Working well.
This issue is resolved. -
Not quite right. DNS lookups are taking longer with VPN load balancing than without. Sometimes failing (timeout), which does not happen for the single VPN case.
This probably is an Unbound configuration issue.
DNS Resolver is using LAN and Localhost for Interfaces, and LAN (no others) for Outgoing network interfaces.So, a port 53 request originating on the LAN (or Localhost) gets converted to a port 853 request and gets routed to the LAN. This port 853 request should bypass Unbound and go to a VPN based on load balancing.
So, what am I missing about this process?
Any hints will be appreciated. -
Another issue. Only when I am running the load balance VPN tunnel pairs, a WAN capture contained:
What are these "ip-proto-17" packets?When I restarted both VPNs, they no longer appear. In the previous case, I restarted pfSense. One VPN started up, the other did not. I manually started it. Later one tunnel stopped carrying traffic and these packets started to appear for the VPN IP that was carrying packets.
The IP address is the VPN server's address.
There seems to be a start up issue. Is there a way to have conditional start ups (dependencies), so only one VPN at a time and after Unbound is set up? -
I have not been able to repeat the "ip-proto-17" issue (UDP is IP protocol #17), so it must have been an anomaly. There is a problem, but it does not appear to be a startup issue. Each VPN client is assigned the same tunnel gateway and subnet by the servers and I used the same client certificate for each one. One or both of these appear to cause clients that are not uniquely defined/identifiable. Continuing to work on this.
-
It appears that the interface is defined by the gateway and/or subnet. Since all the VPN servers use the same subnet for client tunnels, this appears to not be possible. I could find no mapping strategy to get around this issue.
Unfortunately, the client "interface" is not defined as a separate entity using the client certificate for uniqueness, it is derived from the gateway and/or subnet (IP based). So, when the clients are added, the first one defines the interface for IP addressing, the additional ones just cause some confusion.
A 1:1 NAT inside the OpenVPN client to translate the tunnel subnet to a different outward facing one would resolve this issue.
I don't know what else could.
Suggestions will be greatly appreciated. -
@wtw
This is not resolvable without changing OpenVPN to incorporate a 1:1 NAT to completely hide/isolate the conflict from pfSense.
I consider this issue closed.