De provider die ik gebruik is Windscribe. Het downloaden van de Wireguard-profielen voor verschillende eindpunten resulteert in het besef dat alle interface-IP’s hetzelfde zijn.
Sydney Interface IP = 10.100.10.1/32 (mijn interface)
Seoul Interface IP = 10.100.10.1/32 (mijn interface)
etc.. Met dezelfde private/public key voor mijn interface, en verschillende geheime sleutels / openbare sleutels voor de andere kant.
Dit verschilt van alle tutorials die ik heb gezien, waarin je voor elk verschillend eindpunt een aparte interface zou instellen.
Mijn strategie was daarom om alle VPN-eindpunten als peers op één WG-interface in te stellen.
Ik zou alle gedownloade Windscribe-profielen op mijn pc importeren, ze uitvoeren, een traceroute doen, om te zien wat mijn “gateway” is (volgende hop) en die gebruiken bij het toewijzen van de gateway aan die wireguard-interface in pfsense. Het probleem is dat het erg rommelig wordt omdat alle gateways bijvoorbeeld in het 10.60.60.1 bereik liggen, dus wanneer ik het IP aan mijn wireguard-interface in PFSENSE toewijs, moet het subnet dat bereik matchen, anders kan ik geen gateway instellen in een ander subnet. Dit werkt, sporadisch en niet consequent.
Wat *zou* mijn gateway ingesteld moeten worden in een scenario waarin ik 3 VPN-eindpunten wil, maar ik maar één WG-interface met 3 peers kan hebben?
Nu ik er verder mee bezig ben, na het instellen van een externe monitoring IP (bijvoorbeeld 8.8.8.8), en niet het interne VPN-gateway IP (intern adres van de provider), gaat alles groen oplichten en werkt het.
Sommige providers geven unieke adressen uit per unieke sleutelpair. Voor Mullvad moest ik 2 private sleutels genereren en dus 2 aparte configuratiebestanden voor hun eindpunten, en dat gaf mij twee aparte adressen die op twee aparte tunnelinterfaces kunnen worden gebruikt zonder conflicten.
Nog een aanvulling: ik heb het werkend, maar alleen met één VPN-eindpunt. Wireguard weet nog steeds niet hoe te routeren tussen 3 verschillende peers die allemaal een /0 onder de toegestane lijst hebben.
Ik denk dat ik mijn provider moet benaderen om dit te implementeren, met aparte interface-IP / sleutelparen per tunnel.
Ik gebruik een andere provider en heb mijn GW Monitor IP-vakje leeg gelaten, wat blijkbaar prima werkt.
Ik begrijp dat, maar Windscribe niet.
Je krijgt 1 interface (1 private key pair) om alle eindpunten mee te verbinden. Dus de vraag is of ik alle eindpunten onder dezelfde WG-tunnelinterface als WG-peers zet, en de gateways als de volgende interne hop binnen het netwerk van de VPN-provider aangeef, of deze configuratie wordt ondersteund? Zoals ik nu werk, denk ik dat het niet mogelijk is omdat de interne IP-adressen van de gateways in hun netwerken lijken te veranderen.
Een probleem dat naar voren komt bij deze gebruiksgeval is dat je 0.0.0.0/0 onder de toegestane IP’s van alle WG-peers moet zetten, wat niet is hoe wireguard bedoeld is. De tunnel weet niet naar welke peer items moet sturen.
Ook kunnen we geen Aliassen gebruiken in de lijst van toegestane IP’s in wireguard, wat een workaround zou kunnen zijn om bepaald verkeer uitsluitend naar die peers te sturen.
Ik denk dat ik contact opneem met Windscribe om te vragen of dit kan worden aangepast.
Het monitoren van een /32 tunnelinterface is zinloos omdat het vanuit het perspectief van pfSense altijd “up” zal zijn, zelfs als de externe peer niet actief is.
Snap ik. En je hebt gelijk over meerdere WG-peers… de allowed IP’s moeten uniek zijn per peer per tunnel omdat dit wordt gebruikt voor interne routing binnen WireGuard zelf.
Ik onderzoek een mogelijke oplossing hiervoor door een “peer monitoring”-functie te bouwen waarbij je meerdere peers met overlappende allowed IP’s kunt hebben, en een prioriteit kunt definiëren die wordt gebruikt om te bepalen naar welke peer dat verkeer wordt gestuurd. Dit zou je toestaan om een enkele tunnelinterface per provider te hebben, maar meerdere endpoint-peers te configureren waarbij, als een peer uitvalt, WireGuard automatisch de dode peer eruit schudt en de volgende peer in de prioriteitslijst gebruikt. Dit bevindt zich nog in de eerste fase van onderzoek, maar het moet technisch mogelijk zijn.
Geweldig! Ik zal terugrapporteren als ik iets van Windscribe hoor.