Gooit CGNAT roet in mijn WireGuard eten?

[bucovaina89]

Ik probeer thuis een WireGuard VPN op te zetten. Supersimpel: het pivpn maakt er appeltje-eitje van... denk je dan

Lokaal werkt de VPN perfect. Maar als ik 3g/4g aan zet, krijg ik het met geen stokken aan de praat. Ik heb volgens mij port forwarding correct geconfigureerd 51820 op beide TCP en UDP ook al zou TCP niet nodig mogen zijn. Ik heb nog dubbel mijn publiek IPv4 adres gecheckt: correct
Ik heb zelfs mijn Telenet modem in bridge modus gezet om die er ook tussenuit te halen. Maar nothing doin'.

Weet iemand hoe je kan zien of CGNAT de culprit is?

[Mijzelf]

bucovaina89 schreef op dinsdag 1 februari 2022 @ 11:09:
Weet iemand hoe je kan zien of CGNAT de culprit is?

CGNAT is in principe een probleem voor iedere server die afhankelijk is van een publiek IP adres. Bij CGNAT is dat er niet.
Ik weet niet precies wat je bedoelt met je vraag, maar je kunt zien of je achter CGNAT zit door de WAN adres in je router te vergelijken met de output van watismijnip.nl. Als ze afwijken zit er nog een NAT tussen.

[bucovaina89]

Wacht, dan zou ik op mijn modem een adres 100.64.0.0/16 moeten zien (omdat de CGNAT address space daar in zou moeten vallen) en iets anders op "whatismyIP.com". Correct? Server side is dat iig al niet het geval.

De client side ben ik niet zeker van want ik weet niet meteen hoe ik het IP adres kan vinden dat via 3g/4g aan me is toegekend.

[Frogmen]

Het is niet zo heel erg duidelijk wat je nu probeert. Ik krijg het idee dat een wireguard verbinding wilt opzetten naar een server die via 3g/4g verbonden is met internet. (dat gaat niet nooit werken).
Of is het anders probeer even een tekening te maken van het netwerk met de server en de client.

[bucovaina89]

En jawel hoor, volgens mij heb ik van Jan. Mijn rmnet_data device geeft een IP adres aan dat in de range van 10.64.0.0/16 zit.

Dan denk ik dat ik nu moet zien hoe ik mijn config over ipv6 kan laten lopen.

[bucovaina89]

Ja sorry, ik probeer dus een wireguard VPN server thuis op te zetten om de mobiele telefoons van "eender waar" access te geven op het thuis netwerk zonder poorten te hoeven open zetten.

Om mijn basic setup te testen zet ik de wifi aan, activeer wireguard tunnel en jawel, TX en RX. Geen probleem. Ik zet wifi af en mobiele data aan: TX: (requesting handshake) maar geen RX op de telefoon. Ik zie op de server dan ook geen activiteit meer.

Check ik het netwerk device dat verbonden is met de mobiele data op mijn mobiel zie ik idd dat er een netwerkadres is toegekend dat in de range van CGNAT valt.

Dus ik vermoed sterk dat de reden dat ik met mijn mobiel geen verbinding kan maken over 3/4G met mijn WireGuard VPN server CGNAT gaat zijn. Nog een mogelijkheid is mogelijk slechte configuratie van port forwarding maar die heb ik ondertussen 14x nagekeken. Misschien mis ik toch nog iets anders?

[Mijzelf]

Client side zou niet uit moeten maken. Omdat die naar de server verbindt zou het retour verkeer altijd moeten mogen. (De NAT router houd dit soort dingen bij). Wel kan het nodig zijn om een heartbeat te hebben, omdat de UDP 'connectie' door de NAT router wordt gedropt na zoveel tijd inactiviteit. (Aangezien het geen echte connectie is, kun je niet vaststellen wanneer hij 'voorbij' is.) Maar een paar minuten zou hij wel in de lucht moeten blijven.

Over je portforwarding, je zou met wireshark kunnen kijken wat er binnenkomt op de server, als je met de client probeert te verbinden.

[bucovaina89]

Ugh, ik zie helemaal niks gebeuren op de wg0 interface als ik met de telefoon op 3g zit. Maar wel als ik op de WiFi zit. Dat snap ik niet goed. Misschien dan toch een client side setting die niet juist is of port forwarding? ...

[donny007]

bucovaina89 schreef op dinsdag 1 februari 2022 @ 11:59:
Ja sorry, ik probeer dus een wireguard VPN server thuis op te zetten om de mobiele telefoons van "eender waar" access te geven op het thuis netwerk zonder poorten te hoeven open zetten.

Zonder poorten open te zetten gaat het sowieso niet werken, je remote clients moeten natuurlijk wel de VPN-server kunnen bereiken...

Dus ik vermoed sterk dat de reden dat ik met mijn mobiel geen verbinding kan maken over 3/4G met mijn WireGuard VPN server CGNAT gaat zijn. Nog een mogelijkheid is mogelijk slechte configuratie van port forwarding maar die heb ik ondertussen 14x nagekeken. Misschien mis ik toch nog iets anders?

CGNAT aan de kant van de mobiele provider zou in principe niet moeten hinderen bij het opzetten van een verbinding tussen de mobiele client en de server. CGNAT aan de kant van de "vaste" internetprovider gooit wel roet in het eten.

Komt er überhaupt verkeer op de RPi binnen op poort 51820 wanneer je de VPN via 4G probeert te verbinden? Dit kun je checken door met tcpdump op de eth0 interface te luisteren (tenzij pivpn de interface renamed, dan moet je even de juiste opzoeken met ip addr).

code:

sudo tcpdump -nNi eth0 port 51820

[laurens0619]

Tip: Probeer eerst een simpel
Dus bv map de ssh poort van je pi in je modem en kijk of je met een ssh client kan inloggen

[bucovaina89]

Ondertussen weet ik al iets meer. Ik ben bij mijn ouders binnen gesprongen, ik connecteer aldaar op de WiFi (andere internetverbinding) en het werkt zoals verwacht. Dus mijn setup inclusief authenticate/port forwarding is OK.

Wifi AF/3G aan: niks.

[bucovaina89]

donny007 schreef op dinsdag 1 februari 2022 @ 12:38:
[...]


Zonder poorten open te zetten gaat het sowieso niet werken, je remote clients moeten natuurlijk wel de VPN-server kunnen bereiken...

idd geen port forwarding, geen netwerkverkeer dat naar mijn intern genatte WG-server wordt geforward.

[b]donny007 in "Gooit CGNAT roet in mijn WireGuard eten?"
Komt er überhaupt verkeer op de RPi binnen op poort 51820 wanneer je de VPN via 4G probeert te verbinden?

neen. Wel als ik dus 3 straten verder ga en daar ergens op een WiFi verbind

[b]donny007 in "Gooit CGNAT roet in mijn WireGuard eten?"
Dit kun je checken door met tcpdump op de eth0 interface te luisteren (tenzij pivpn de interface renamed, dan moet je even de juiste opzoeken met ip addr).

Heb ik gedaan met iptraf. Over 3g/4g hoort die op de wg0 interface nul komma nul. Switch ik naar WiFi zie ik wel UDP over en weer vliegen.

[donny007]

[b]bucovaina89 schreef op dinsdag 1 februari 2022 @ 12:49:
Heb ik gedaan met iptraf. Over 3g/4g hoort die op de wg0 interface nul komma nul. Switch ik naar WiFi zie ik wel UDP over en weer vliegen.

wg0 is een virtuele interface waar de VPN-tunnel op uitkomt, daar ga je dus pas activiteit zien nadat de verbinding tot stand is gekomen.

Eerst moet het verkeer door een LAN-interface (eth0 of whatever) om bij de WireGuard server te komen, de vraag is dus of daar wel iets te zien is wanneer je verbinding maakt via 4G...

Controleer ook de configuratie van de client: juiste IP-adres, juiste poort, juiste protocol?

[bucovaina89]

Ah kijk. Ik zie wel activiteit op /dev/eth0. Maar telkens 1 pakketje. Ik vermoed poging tot handshake, die telkens faalt. Maak ik connectie via WiFi (lokaal dan), dan zie ik veel meer gebeuren met tcpdump, iets wat ik veel meer zou associëren met een correct werkende setup.

code:

root@stats:/home/pi/configs# tcpdump -nNi eth0 port 51820
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:09:49.228506 IP 10.10.10.3.51820 > 95.119.115.235.16805: UDP, length 148
13:09:54.988807 IP 10.10.10.3.51820 > 95.119.115.235.16805: UDP, length 148
13:10:00.108276 IP 10.10.10.3.51820 > 95.119.115.235.16805: UDP, length 148
13:10:04.173152 IP 95.119.115.235.16712 > 10.10.10.3.51820: UDP, length 148

edit:
typo

[bucovaina89]

Ik gebruik trouwens 10.10.10.0/24. Ik vermoed dat dat geen clash kan geven met 10.64.0.0/16?

edit:
Voor alle zekerheid dubbel gecheckt, staat idd op 10.10.10.0, subnet mask 255.255.255.0, dus mijn netwerk kan niet aan de range 10.64/16. Voor zover mijn netwerk kennis reikt tenminste

.

[Voor 52% gewijzigd door bucovaina89 op 01-02-2022 13:22]

[laurens0619]

Vaag. Zou het kunnen dat je mobiele verbinding misschien iets tegen de poort 51820 heeft?
heb je het al eens op 443/53 oid geprobeerd?

[krijn1985]

Kun je eens de config van je server en je client posten (haal dus eventuele private keys uit je config!!)? Bij mij werkt wireguard via 4G prima namelijk. Ik gebruik dan geen PiVPN maar dat zou denk ik niet veel moeten uitmaken.

[bucovaina89]

Net geprobeerd om mijn telenet modem 1890 extern naar 51820 intern te laten forwarden naar mijn interne router en mijn interne router gewoon 51820 naar 51820 te laten doorsturen op de wg server. Dan de config op de client aangepast zodat die op 1890 gaat proberen op mijn publiek IP. Ik zie weer wat volgens mij poging tot handshakes is, op /dev/eth0 (NAT/port forwarding config correct) maar nog altijd krijg ik geen werkende verbinding tot stand. WiFi werkt nog steeds dus in de basis is er niets mis zou ik dan denken.

code:

root@stats:~# cat /etc/wireguard/wg0.conf 
[Interface]
PrivateKey = REDACTED=
Address = 10.6.0.1/24
MTU = 1420
ListenPort = 51820
### begin REDACTED ###
[Peer]
PublicKey = BLAH=
PresharedKey = BLAH=
AllowedIPs = 10.6.0.2/32
### end REDACTED ###
### begin REDACTED ###
[Peer]
PublicKey = BLAH=
PresharedKey = BLAH=
AllowedIPs = 10.6.0.3/32
### end REDACTED ###
### begin REDACTED ###
[Peer]
PublicKey = BLAH=
PresharedKey = BLAH=
AllowedIPs = 10.6.0.4/32
### end REDACTED ###
root@stats:~#

[krijn1985]

bucovaina89 schreef op dinsdag 1 februari 2022 @ 13:15:
Ah kijk. Ik zie wel activiteit op /dev/eth0. Maar telkens 1 pakketje. Ik vermoed poging tot handshake, die telkens faalt. Maak ik connectie via WiFi (lokaal dan), dan zie ik veel meer gebeuren met tcpdump, iets wat ik veel meer zou associëren met een correct werkende setup.

code:

root@stats:/home/pi/configs# tcpdump -nNi eth0 port 51820
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:09:49.228506 IP 10.10.10.3.51820 > 95.119.115.235.16805: UDP, length 148
13:09:54.988807 IP 10.10.10.3.51820 > 95.119.115.235.16805: UDP, length 148
13:10:00.108276 IP 10.10.10.3.51820 > 95.119.115.235.16805: UDP, length 148
13:10:04.173152 IP 95.119.115.235.16712 > 10.10.10.3.51820: UDP, length 148

edit:
typo

Dit stukje tcpdump probeer je hier via wifi of via 3G/4G verbinding te maken? En kan je nog je client config posten? En wat voor een apparaat gebruik je als client, iOS, android?

[bucovaina89]

Ik gebruik een Android op een OnePlus 6. De tcpdump dump is van tijdens dat ik op 4g verbonden benprobeer te geraken. Je ziet op de Android client 148bytes sent, op /dev/eth0 van de wg server zie je 148bytes toekomen, maar dan niets meer voor 5 seconden tot de Android client opnieuw een poging tot handshake stuurt. Switch ik de Android naar wifi, werkt alles zonder meer te doen dan wifi aan te zetten en 4g af. Switch ik terug naar 4g, valt de "verbinding" weer weg. Dit dus ook als ik op een andere locatie zit die vereist van over het internet een verbinding aan te leggen.

Van binnenuit weet ik niet exact hoe het werkt maar hij gaat wel degelijk via de publieke IP moeten gaan omdat ik poort 1890 heb gezet op de client, en die staat op mijn lokale infra nergens open, wel op de telenet router op de WAN kant.

code:

[Interface]
PrivateKey = BLAH=
Address = 10.6.0.2/24
DNS = 9.9.9.9, 149.112.112.112 #heb ik op de client aangepast naar de interne DNS-server maar de gateway pingen gaat zelfs niet

[Peer]
PublicKey = BLAH=
PresharedKey = BLAH=
Endpoint = [MIJN-THUIS-IP-HIER]:51820 #tijdelijk 1890 maar oorspronkelijk op 51820
AllowedIPs = 0.0.0.0/0, ::0/0

[krijn1985]

Ik zie volgens mij geen vreemde dingen (al ben ik geen expert). Ik maak zelf geen gebruik van preshared key maar als je blijkbaar gewoon kan verbinden op wifi zal dat geen probleem moeten zijn. Daarnaast zie ik wel dat je op de server 10.6.0.2/32 gebruikt in en je client 10.6.0.2/24, je zou deze ook nog even naar 32 kunnen zetten.

Paar dingen die ik voor de zekerheid zou nakijken:
1. De publickey in je wg0.conf op de server voor peer 10.6.0.2 is de publickey van je client?
2. De publickey in je client config bij Peer is de publickey van je server?
3. Is mijn-thuis-ip-hier correct?

Al vind ik het vooral apart dat het op Wifi wel zou werken en via 4G niet. Hier werkt het namelijk prima via mijn provider. Ik weet niet welke mobiele provider je hebt, maar het zou inderdaad nog kunnen dat die iets niet doorlaten.

[bucovaina89]

@krijn1985 : ik zou idd verwachten dat als ik thuis over WiFi succesvol een WG tunnel kan aanleggen naar mijn wg server dat de basic setup werkt. Al helemaal als ik van bij iemand anders thuis over WiFi een WG tunnel kan aanleggen.

Ik heb de client naar /32 aangepast. Idd wat bizar dat het op /24 stond maar het komt uit het script dus in principe denk ik dat dat ook zou moeten werken.

1. public key: geverifieerd en correct
2. Ook geverifieerd en correct
3. Yep. Wordt ook bevestigd doordat ik via WiFi vanaf iemand anders' huis wel kan verbinden.

Maar het blijft wel: Over Wifi remote werkt het wel. Dus dat bewijst wel dat mijn setup werkt. Er is iets tussen mijn telefoon/3G en mijn Telenet modem dat ervoor zorgt dat het niet werkt. Dat "iets" is er niet tussen mijn telefoon-wifi-NIC en mijn telenet modem thuis. Ik wil gerust geloven dat CGNAT er niets mee te maken kan hebben , maar wat dan wel?

[krijn1985]

Dan zou ik zoals @laurens0619 suggereerde eens proberen of je bijvoorbeeld wel naar SSH kan verbinden via 4G. Lukt dat op poort 22, gooi hem in je router eens op een hoge poort (bijvoorbeeld 1890 of 51820) en kijk of je dan nog kan verbinden. Lukt het niet op poort 22 probeer dan inderdaad eens via poort 80 of 443 bijvoorbeeld.
Of zoek eventueel of je online kan vinden of je mobiele provider poorten blokkeert.

[Mijzelf]

bucovaina89 schreef op dinsdag 1 februari 2022 @ 14:01:
Je ziet op de Android client 148bytes sent, op /dev/eth0 van de wg server zie je 148bytes toekomen, maar dan niets meer voor 5 seconden tot de Android client opnieuw een poging tot handshake stuurt.

Dus de poging tot communicatie wordt serverside gedropt. Blijkbaar is er iets met die pakketjes. Als je kernel dynamic debugging ondersteund, (je hebt dan een file ' /sys/kernel/debug/dynamic_debug/control'), zou je debugging voor wireguard aan kunnen zetten met

echo 'module wireguard +p' > /sys/kernel/debug/dynamic_debug/control 

De debug info kun je dan zien met dmesg

Verder kun je tcpdump de pakketten opslaan (met -w <file.pcap>) en die kun je vervolgens met wireshark bekijken om te zien of wireshark commentaar heeft.

[bucovaina89]

Het wordt raar.

SSH werkt gewoon. Login succesvol op poort 1890 WAN naar 51820 intern (serverside ff wg-quick down && /usr/sbin/sshd -ddd -p 51820)

Dus dezelfde pakketten, dan wel tcp, geen UDP

edit:
voor alle duidelijkheid: ik heb de portforwarding gewijzigd van UDP naar TCP om de SSH test te kunnen doen. Port forwarding heeft al op UDP gestaan en op TCP & UDP zonder succes.

[Voor 31% gewijzigd door bucovaina89 op 01-02-2022 15:13]

[laurens0619]

Iets met mtu misschien?

[bucovaina89]

Ik heb beide server en client de MTU eens op 900 gezet. Helpt ook niets.

edit:
en client nog lager naar 400. Same thing

[Voor 28% gewijzigd door bucovaina89 op 01-02-2022 16:14]

[bucovaina89]

zou het kunnen dat UDP anders wordt behandeld dan TCP ergens tussen mijn router en mijn GSM?

edit:
ondertussen ook telenet modem eens naar fabrieksinstellingen gezet, nothing doin'

[Voor 34% gewijzigd door bucovaina89 op 01-02-2022 16:43]

[donny007]

bucovaina89 schreef op dinsdag 1 februari 2022 @ 13:15:
Ah kijk. Ik zie wel activiteit op /dev/eth0. Maar telkens 1 pakketje. Ik vermoed poging tot handshake, die telkens faalt. Maak ik connectie via WiFi (lokaal dan), dan zie ik veel meer gebeuren met tcpdump, iets wat ik veel meer zou associëren met een correct werkende setup.

code:

root@stats:/home/pi/configs# tcpdump -nNi eth0 port 51820
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:09:49.228506 IP 10.10.10.3.51820 > 95.119.115.235.16805: UDP, length 148
13:09:54.988807 IP 10.10.10.3.51820 > 95.119.115.235.16805: UDP, length 148
13:10:00.108276 IP 10.10.10.3.51820 > 95.119.115.235.16805: UDP, length 148
13:10:04.173152 IP 95.119.115.235.16712 > 10.10.10.3.51820: UDP, length 148

edit:
typo

Dat 95.119.x.y adres is van Telefonica Germany, zie je dit IP ook wanneer je via 4G naar ifconfig.me (of een gelijkwaardige website) browsed?

bucovaina89 schreef op dinsdag 1 februari 2022 @ 16:19:
zou het kunnen dat UDP anders wordt behandeld dan TCP ergens tussen mijn router en mijn GSM?

edit:
ondertussen ook telenet modem eens naar fabrieksinstellingen gezet, nothing doin'

Zet anders even een hotspot op met je telefoon en gebruik een laptop met WireGuard client om, via die hotspot, een VPN-connectie op te zetten. Als dat wel werkt dan kun je het mobiele netwerk uitsluiten.

[bucovaina89]

Oei sorry, het IP adres moet je niet op letten. Dat had ik manueel veranderd in de output om mijn echte IP niet zomaar online te posten .

Ondertussen zie ik met tcpdump al wel een verschil. Geen idee hoe het komt maar nu stuurt hij wel degelijk pakketten terug. Die komen nooit op mijn mobiel aan want de RX stats van de connectie blijft op 0 bytes staan terwijl de TX (handshake initiation?) telkens met 148 bytes omhoog gaat.

En nog steeds zo, als ik overschakel op wifi gaan de stats van RX plots wel omhoog en weet ik dat de connectie geslaagd is.

code:

root@stats:~# tcpdump -nNi eth0 port 51820
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:32:17.792701 IP 95.119.115.235.29587 > 10.10.10.3.51820: UDP, length 148
17:32:17.795155 IP 10.10.10.3.51820 > 95.119.115.235.29587: UDP, length 92

[bucovaina89]

OK en het wordt nog raarder .

Ik heb een config file naar de iPhone van mijn vrouw doorgestuurd and all was fine. Zij zit ook bij Orange met de GSM. Dus het ligt al niet aan Orange / MTU / ...

Nu heb ik opnieuw een config gegenereerd en naar mijn Android gepushed ... No luck met 4G, werkt nog steeds wel met WiFi.

Ik krijg er kop noch staart aan. Hoe kan dit nu in mijn GSM zitten? App permissies gaan toch niet TX toelaten en RX blokkeren?

[bucovaina89]

Ik hou het vooralsnog op een bug in de WireGuard.app op mijn OnePlus6. Ik krijg die met geen stokken aan de praat op 3G/4G. Met WiFi werkt die perfect normaal (nu ook getest vanaf de WiFi van mijn werk) en de iPhone van mijn vrouw doet het ook gewoon wel op 3G/4G. Ook ondertussen mijn Mac geprobeerd vanop het werk. Allemaal geen probleem.

[jvanhambelgium]

Ik herinner me allesinds dat ik (ook) serieus heb moeten prullen met die Wireguard for Android v1.0.20211029 versie hier op m'n Galaxy S21
Ik denk zelfs dat ik uiteindelijk "create from scratch" gedaan heb want iets "importeren" via een Wireguard config-generator ging dus gewoon niet. h

https://www.wireguardconfig.com/

Verder is er inderdaad niet gek veel in stellen, ik gebruik geen "Keepalives" , doe client-side gewoon een 0.0.0.0/0 dus alles in de tunnel.

Ik heb than 2 systemen die ik gebruik ; Wireguard & ZeroTier.
(naar die laatste moet je zeker eens kijken, je eigen "cloud switch")
Beide apps op m'n phone en langs de andere kant een Mikrotik

[bucovaina89]

@jvanhambelgium : Het is me vooral te doen om thuis te kunnen connecteren op de Home Assistant zonder poorten open te hoeven zetten. Zelden heb ik alleen maar 3G/4G én geen wifi én sterke nood aan direct op het thuisnetwerk te moeten én ook de iPhone van mijn vrouw niet beschikbaar.

Het had leuk geweest had ik dit gefixt gekregen maar ik kan er best mee leven. Ik wacht gewoon tot er een update in F-droid staat die het hopelijk verhelpt.

[prutser001]

Vraagje, waarom perse wireguard? Zelf gebruik ik eblocker met OpenVPN en dat werkt ootb.

OpenVPN zit dus ingebakken in eblocker.

[bucovaina89]

Er valt wat mij betreft veel voor te zeggen. Erg weinig overhead (zowel op de machine als over het netwerk) en buiten deze "bug" simpel op te zetten en weinig configuratie nodig. Ik draai het op een RPI4 waar ook wat andere dingen op draaien. Dan is het fijn om low profile te kunnen blijven gezien de relatief beperkte compute resources.

Ook voor elk OS dat ik gebruik bestaat er een client die relatief eenvoudig te configureren is. Alleen doet Android nu wat vervelend, maar zoals eerder is dat wat mij betreft is het nice to have mocht ik dat 3G/4G probleem opgelost krijgen, maar ook niet meer dan dat. Het is puur voor thuisgebruik

[Ben(V)]

bucovaina89 schreef op dinsdag 1 februari 2022 @ 14:41:
@krijn1985 : ik zou idd verwachten dat als ik thuis over WiFi succesvol een WG tunnel kan aanleggen naar mijn wg server dat de basic setup werkt. Al helemaal als ik van bij iemand anders thuis over WiFi een WG tunnel kan aanleggen.

Ik heb de client naar /32 aangepast. Idd wat bizar dat het op /24 stond maar het komt uit het script dus in principe denk ik dat dat ook zou moeten werken.

Ik zou ze beiden maar op /24 zetten anders, want een subnetmask van /32 geeft je een subnet van maar 1 ipadres.
http://jodies.de/ipcalc?h...2.168.0.1&mask1=32&mask2=

[Voor 29% gewijzigd door Ben(V) op 03-02-2022 10:21]

[bucovaina89]

@Ben(V) : de client krijg adres 10.6.0.2/32. De server heeft subnet 10.6.0.0/24. Of ik de client nu 10.6.0.2/32 of 10.6.0.2/24 als adres mee geef, verandert niets aan die ~bug (or whatever is is)

[Ben(V)]

Ok ik ken wireguard niet voldoende blijkbaar.
Als ik het beter bestudeer staat hij drie ipadressen toe te weten

AllowedIPs = 10.6.0.2/32
AllowedIPs = 10.6.0.3/32
AllowedIPs = 10.6.0.4/32

Daar moet volgens dus wel degelijk /32 staan (of helemaal niets), want dat gaat steeds over een enkel ipadres, als je daar /24 van maakt is het ineens het hele subnet dus 10.6.0.0 tot 10.6.0.255

En hij luistert op poort 51820 van het hele subnet want /24
Werkt het zo met wireguard?

[FreshMaker]

jvanhambelgium schreef op donderdag 3 februari 2022 @ 08:08:

Ik heb than 2 systemen die ik gebruik ; Wireguard & ZeroTier.
(naar die laatste moet je zeker eens kijken, je eigen "cloud switch")
Beide apps op m'n phone en langs de andere kant een Mikrotik

Zerotier is geweldig, maar kijk ook eens naar Tailscale ..

Ik heb momenteel prima ervaringen met Tailscale, en deze breiden regelmatig uit met nieuwe functies.

https://tailscale.com/

[Hann1BaL]

Je zegt dat het niet werkt op jouw telefoon maar wel op die van je vrouw.

Beschikt die over hetzelfde mobiele netwerk?
Je kunt eens kijken of het werkt op de telefoon van je vrouw als ze verbonden is via jouw telefoon als hotspot.
Dan check je dus jouw mobiele data met haar telefoon en configuratie.

[bucovaina89]

@Hann1BaL : OK ik heb het opgelost gekregen. Databesparing stond gewoon aan.

Ik ben erop gekomen door jou comment om eens een hotspot op te zetten. Dat had ik zelf al eens willen proberen met dit issue te debuggen, maar sinds lange tijd staat die optie bij mij greyed out. Ik had al eens liggen zoeken maar nooit echt gevonden waarom. Dat was dus omdat Databesparing aan stond. Nu ik die af zet, werkt plots mijn hotspot weer, en nog veel belangrijker, mijn WireGuard VPN ook weer.

Ik ben weer gelukkig

[jvanhambelgium]

FreshMaker schreef op donderdag 3 februari 2022 @ 10:36:
[...]


Zerotier is geweldig, maar kijk ook eens naar Tailscale ..

Ik heb momenteel prima ervaringen met Tailscale, en deze breiden regelmatig uit met nieuwe functies.

https://tailscale.com/

Klopt wel, maar ik zoek een native integratie met m'n Mikrotik, vandaar TailScale geen optie voor mij.
In een bedrijfscontext met vb honderden peers is TailScale idd héél vlot te deployen

[krijn1985]

@bucovaina89 Mooi dat het opgelost is. Wel apart eigenlijk dat de app wel mag sturen ik wil verbinden, maar verbinding maken helemaal niet kan.

[bucovaina89]

krijn1985 schreef op donderdag 3 februari 2022 @ 11:46:
@bucovaina89 Mooi dat het opgelost is. Wel apart eigenlijk dat de app wel mag sturen ik wil verbinden, maar verbinding maken helemaal niet kan.

Pakketten versturen lijkt toegestaan, maar luisteren op pakketten die daarop terug komen lijkt uit te staan, dat leid ik af uit TX waarvan de teller omhoog ging en RX die op 0 bytes bleef staan terwijl de tcpdump op de server wel degelijk aan gaf dat er pakketten werden verstuurd.

Vandaar ook mijn eerste verwarring met CGNAT.