The provider I use is Windscribe. Downloading the Wireguard profiles for various endpoints results in realizing that all interface IPs are the same.
Sydney Interface IP = 10.100.10.1/32 (my interface)
Soeul Interface IP = 10.100.10.1/32 (my interface)
etc… With the same private/public key for my interface, and different secret keys / public keys for the other side.
This differs to all tutorials I’ve seen where you would setup one separate interface for each different endpoint.
My strategy then was to setup all the VPN endpoints as peers on one WG interface.
I would import all the downloaded Windscribe profiles to my PC, run them, run a trace route, to see what my “gateway” is (next hop) and then use that when assigning the gateway to that wireguard interface in pfsense. The problem is it gets very messy as all the gateways are say, in the 10.60.60.1 range, so when I assign the IP to my wireguard interface in PFSENSE, the subnet needs to match that range otherwise I can’t set a gateway in a different subnet. This works, sporadically and not consistently.
What *should* my gateway be set to in a scenario where I want 3 vpn endpoints, but I can only have one WG interface with 3 peers?
Now that I’m working with it farther, after I setup an external monitoring IP (say, 8.8.8.8), and not the internal VPN gateway IP (internal address of the provider), everything lights up green and works.
Some providers will dish out unique addresses per unique keypair. For Mullvad, I had to generate 2 private keys and thus 2 separate sets of conf files for their endpoints, and this gave me two separate addresses that can be used on two separate tunnel interfaces without conflicts.
Just an addition to this, I have it working, but only with 1 VPN endpoint. Wireguard still doesn’t know how to route between 3 different peers that all have a /0 under the allowed list.
I think I have to reach out to my provider for this one to implement separate interface IP /key pairs per tunnel.
I’m using another provider and have left my GW Monitor IP box blank which seems to work fine
I understand that, but Windscribe does not.
You get 1 interface (1 private key pair) to connect to all endpoints. So question is if I put all the endpoints under the one WG tunnel interface as WG peers, and declare the gateways as the next internal hop within the VPN provider network, is this configuration supported? As I’m working with it now, I think it’s not possible as the internal IP addresses of the gateways in their networks seem to change.
Some problems that I think are apparent in just this use case is you need to put 0.0.0.0/0 under the allowed IPs of all the WG peers, which isn’t how wireguard is supposed to work. The tunnel won’t know which peer to send items to.
Also we can’t seem to use Aliases in the Allowed IP list in wireguard which could be a workaround to send out certain traffic to only those peers.
I think I’ll be reaching out to windscribe to see if this can be modified.
Monitoring a /32 tunnel interface is pointless because from the perspective of pfSense, it will always be “up” even if the remote peer isn’t.
Gotcha. And you are correct about multiple WG peers…the allowed IPs must be unique per peer per tunnel as this is used for internal routing within WireGuard itself.
I am exploring a potential solution to this by building a “peer monitoring” capability where you CAN have multiple peers with overlapping allowed ips, and define a priority that will be used for picking which peer to send that traffic towards. This would allow you to have a single tunnel interface per provider, but have several endpoint peers configured where if one fails, WireGuard will automatically shuffle the dead peer out and swap in the next peer in the priority list and try again. This is still early in the exploration phase, but it should be technically possible.
Awesome! Will report back if I get anywhere with windscribe.