OpenVPN "The Clash of Gateways"
-
@JeGr I don't know exactly what you mean, besides the usual basic configurations of a VPN as shown in VPN providers' guides on their website. Also, I didn't see (probably missed it or something) an option to edit the gateway's IP.
In the screenshot below you can see that is says "dynamic" for the gateway's IP address and it's a grey disabled box, so I can't change it and assign my own choice there :(
-
You need to use VPN services without the same gateway address.
-
@Derelict Not sure I fully understand...
(1) These are 4 different servers why would they obtain the same inner/local virtual gateway IP address?
(2) Would other, more distant servers work?
(3) Should I ask my VPN provider on that matter? (already did btw)Update #1: They obtain different addresses if I refresh them. The prefix of 10.8. remains though...
Update #2: After quoting your answer to my VPN service provider they suddenly had an answer (unlike yesterday): "You need to pick other servers that don't clash between them". That's what you meant I guess?...
Update #3: I feel like a noob but this is my final understating after talking to my VPN SP - The gateway addresses are "hard wired" and defined on the remote server. They change based on the protocol you choose, so multiple VPN servers using the same protocol on the same interface (for example: LAN, gateway group of UDPs) will create clashes.
Apparently the reason it worked well for months was a miracle or a crazy statistical anomaly lolUpdate #4: What I want to achieve is this: I have 1 WAN connection and I want to be connected to a multiple OVPN instances in order to have load balancing & failover. Would a multiple VPN in a Gateway Group, like I have now, be the way to go?
Btw, I use "Sticky Connections" in the configurations in order to avoid rapid IP changes and the problems it brings with it, but when performing a speed test or even just surfing the web I see that there's always 1 VPN instance/connection that takes 99% of the load, which doesn't seem like load balancing but on the other hand maybe something is happening behind the scenes that I don't know of. Any idea how to fix the issue above (clash) and also achieving what I've just described here? -
As I said, check your tunnel settings or the tunnel settings of your VPN providers.
Every OVPN Server (and Client) has a tunnel network defined between them. If your 4 VPN providers all use the same network you have an IP/Gateway conflict. Simple as that. If everyone has configured 10.8.0.x/24 you have your problem.
-
Looks like NordVPN do:-
I wonder if they roll the same config out on their boxes assuming people just connect once from one device.
-
@JeGr Yeah...just talked to NordVPN and their servers obviously handle it themselves so I must leave blank and deal with this issue in another way.
Thanks,@NogBadTheBad Hmmm I thought so...So what do I do? Use only 2 servers in that gateway group with different protocols (1 TCP, 1 UDP) or use a different approach (if there is one) for Load Balancing & Fail-over?
-
I'd just have 3 servers and hope
At the end of the day if Nord are handing out the same ip range to the clients it doesn't really matter from their point of view as most people will only connect the once from the NordVPN client and they'll just work.
I'm guessing they have a standard config that they roll out to all their servers.
-
@NogBadTheBad Apparently cases like this are seen as "extreme cases" to them so why bother SMH...
-
@NogBadTheBad What about the Load Balancing issue I mentioned? - Doesn't seem like load balancing when 99% of the traffic goes through 1 of the servers. On the other hand, without "Sticky Connections" many problems arise.
Also, is this the way to achieve fail-over? Or is there another way to create multiple 1-2 VPN gateways and have the desired Netwrok interfaces dynamically change their gateway to what ever is available and online (besides just the default WAN)?
Thank you for your patience,
-
I just use a gateway group with 3 tiers and TBH I only added 3 to play with gateway groups.
IIRC if you set two the same tier level they load balance.
https://docs.netgate.com/pfsense/en/latest/routing/gateway-settings.html
-
@NogBadTheBad
(1) I did set all of them to Tier 1. So you're saying that even though I don't see the traffic on all of them in the graphs they still load balancing, or you're saying that if I don't see it they probably don't load balancing and I should set same Tier level (which I did)?(2)
A gateway group is also the only/best solution for a fail over? Or it could be done dynamically as I described?Ok, my bad. Misunderstood the possibilities with a gateway group. Fail over is perfectly manageable with Tier numbers/priorities lol...sorry.(3) Below is the answer from one of NordVPN's support guys:
-
I just tried a traceroute to 8.8.8.8 from two different devices connected to my NORD LAN after setting AU connection to be the same tier as the US connection.
A traceroute from one device shows a US route as the first hop and the other device shows an AU route.
Both devices use the same gateway group.
-
@NogBadTheBad So the load balancing won't necessarily (or maybe never) split the load when only one device is creating traffic...but when multiple devices "join the party", it kicks in. Did I get it right?
-
Yup it round robins.
-
@NogBadTheBad Ok, thank you you're the man. It actually says "round robins" somewhere around the "Use Sticky Connections". But isn't round robins suppose to send packets that come from the same source through different routes?
So, again, and sorry for repeating myself, you're saying that round robins would kick in only when multiple devices join in?Update: It won't be "efficient" sort to speak and maybe slow, to use round robin for traffic coming from the same device?
-
Yup one gateway, then the next, then the first ...
-
When you connect to a VPN server it gives you a gateway address. If you connect to servers that give you the same gateway you will have the problems you are seeing because you can't have two interfaces with the same subnet/gateway on them. Choosing different access points from the same provider, or different providers, should solve it.