NordVPN using same virtual address for multiple gateways/interfaces
-
Nord recently has started always using returning 10.100.0.2 for all openvpn virtual addresses (Nord support has confirmed this saying using different is a "security" issue).
Because of this, my prior happily working usage of routing different devices to different Nord destinations no longer works
Using UDP/TCP makes no difference as same gateway IP is used (I have tried).
Ticket 188567 is indirectly describing this issue with no prartical reply
Ticket 176579 had similar issue but using wireguard- With wireguard there is the option to redefine the interface/gateway IP address, and I can see the user dma_pf solution working for wireguard.
- However with OpenVPN it appears the gateway address cannot be redefined...shows "dynamic" when the service is down and the 10.100.0.2 address when up...thus not allowing the routing described in 176579
Is there any possible solution path for multiple OpenVPN gateways to co-exist with the same virtual IP address on pfSense?
TIA
-
@jmbraben I don't think so.
-
Mmm, I'm not aware of any solution to that issue that can be applied at the client end.
What happens now? All traffic is routed over the same VPN?
-
@stephenw10 yes, all traffic goes through one gateway... seems to be the first vpn connection started
-
There are some NAT values you can set in OpenVPN directly using the custom command field but I don't think you can apply those to the gateway.
-
At this point, I'm going to try to switch to using wireguard from Nord.
Wireguard is technically unsupported by Nord outside their application, but it seems it "can be done"
If I can get their vpn running with Wireguard, I'll try the 176579 path. -
Hello,
Did you manage to implement the wireguard based workaround?
For my part, I have the same problem and I haven't been able to force different IPs.Thank you in advance
Stephane
-
@SCU said in NordVPN using same virtual address for multiple gateways/interfaces:
Did you manage to implement the wireguard based workaround?
Yes and no...I do have Nord Wireguard running on pfSense.
I did get multiple instances running as described in 176579
What I did:
From what I can see, Nord WG internal IP is 10.5.0.2
So for my interfaces, I created one at 10.5.0.128 and one at 10.5.0.129
And then in the Firewall/NAT/Outbound I added mappings that routed the appropriate interfaces/sources to a NAT Address of 10.5.0.2 (rather than the typical "Interface Address")However:
I started getting large numbers of dropped packets on both WG interfaces...to the point it was not usable.As short term solution (as I currently only need 2x Nord interfaces), I set one to OpenVPN and one to Wireguard (and that has been working fine)
In retrospect, I am realizing that when I configured the interfaces, their subnets were /32 (and obviously 10.5.0.2 not in the subnet...not sure if that is part of the dropped packets)...and if changed their subnets to include 10.5.0.2 then they would obviously overlap...but not sure it would matter. @stephenw10 ...any thoughts on how the interface subnet should be configured (or any other idea why the packets would be dropping)?
-
Wireguard is not flagged as a point to point interface so I'd expect to require the subnet to cover both ends of the tunnel at least.
However it is isn't then I'd expect no traffic to pass. High packet loss but still passing some traffic sounds more like a conflict with updates switching the gateway used.
I would run some packet captures to what's actually passing the tunnels.
-
@jmbraben : Hello,
Did you configure 2 Gateways (ie 10.5.0.128 and one at 10.5.0.129) as described in 176579 ?
*"The key thing that worked for me is that the 3 interfaces/gateways have to have unique IP addresses and they can't be the IP address that the VPN provider wants you to use.
So in my case, ProtonVPN wants all connections to all their servers to use 10.2.0.2/32. So I set my 3 interfaces/gateways to use the IPs of 10.2.0.3/32, 10.2.0.4/32 & 10.2.0.5/32. Then set the NAT for each Interface as I showed in my picture above.
In my case, using the 10.2.0.2 IP for any of the interfaces messed up the NAT due to the "reply-to" rule that's automatically applied to that interface. The reply-to rule preempts the custom NAT rules and would return packets back to the 10.2.0.2 interface. Big kudos to @stephenw10 for figuring that out!
(Way over my pay grade)"*If yes, is it possible for you to publish some screen capture of them : i did not success to configure properly these gateway, and i would like to know were i make mistake ...
Or my problem is at the NAT rules level ... If you can show this config too.
With this I can check if i am the same bahavior than you :o(
Thanks in advance
Stephane
-
@SCU yes, I configured as 176579...and it "kinda" worked, but it was unreliable due to packet loss.
I have torn it all down for the more straight-forward OpenVPN + WG, but I'll put it back together when I get some time and run some packet captures to try and figure out what is going on. -
Thanks
