Hello,
Some time ago I successfully set up the WireGuard Road Warrior Setup (https://docs.opnsense.org/manual/how-tos/wireguard-client.html).
Now recently I configured a wireguard connection to ProtonVPN from my gateway using
this:
WireGuard ProtonVPN Road Warrior Setup (https://docs.opnsense.org/manual/how-tos/wireguard-client-proton.html)
and this:
WireGuard Selective Routing to External VPN Endpoint (https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html)
Initially I could not get the ProtonVPN connection to work, but learned that when I disable the Road Warrior instance the ProtonVPN connection works.
With the Road Warrior instance on, and I turned on the ProtonVPN instance, I get this error:
/usr/local/opnsense/scripts/wireguard/wg-service-control.php: The command '/sbin/route -q -n add '-4' '10.2.0.1' -iface 'wg2'' returned exit code '1', the output was ''
My conclusion is basically that wireguard's attempt at adding a new route to interface wg2 failed. I have no idea how to fix this.
Does anyone understand why there is a conflict between the Road Warrior setup and the ProtonVPN setup?
Thanks
Potentially, there is an overlap for the respective VPN networks? You also should have different VPN instances for this to work (it does for me).
meyergru, that's a reasonable guess. They only thing in common with the two instances and peers is the port, 51820. But I don't see why the use of that standard port would affect the ability to add a static route on interface wg2. I guess it's possible that the error regarding adding a static route on interface wg2 is a red herring, but I don't see any other errors.
I would love to test different things, but I don't even know where to start testing.
Interesting, I never tried to have two instances on the same port. Does that even work? This could effectively be your problem.
The more I think of it, the more convinced I am: WIth the old WG implementation, each instance would have its own process, which binds exclusively to the port. I suppose that with the new implementation, a similar thing happens. And when I look at my sockstat output, I can see something to that effect:
? ? ? ? udp4 *:601 *:*
? ? ? ? udp6 *:603 *:*
? ? ? ? udp4 *:603 *:*
? ? ? ? udp6 *:601 *:*
? ? ? ? udp6 *:602 *:*
? ? ? ? udp4 *:602 *:*
Guess what? 601, 602 and 603 are the different port for my 3 instances.
P.S.: If you alter your ports, remember to open them via firewall rules.
Success! Yeah, clearly you have to have different instances on different ports, and in retrospect that makes perfect sense. Thanks for your help.
So, do you know if I set up another ProtonVPN tunnel I can just change the port, or am I constrained by the port Proton indicates?
The destination port is determined by the VPN provider and you set these in the peer, not in the instance.
Your corresponding local instance is usually not contacted from outside, because the VPN connection is initiated from your end in these cases. Thus, for a VPN instance that is being used for a "provider" VPN, you do not even need to open any ports - this is only used for site-2-site or roadwarrior setups.
With mit P.S. above, I was referring to the latter two types.