Unifi USG-3P VPN routeert niet naar corporate netwerk

[Galileo_Galilei]

Mijn vraag
Ik heb een Unifi USG 3P waar een corporate netwerk en een WAN op draait. In het Corporate netwerk hangt ook nog een andere gateway waarmee je naar het hele corporate netwerk en de servers die daar binnen hangen kan benaderen. Het reguliere internet verkeer gaat via de WAN verbinding, maar de interne applicaties horen dus via de 2e gateway te gaan.

Dat lukt bij de direct verbonden apparaten prima door middel van een static route (10.0.0.0/8 next hop 10.52.9.254). De USG draait zelf op 10.52.9.253 en de DHCP scope ligt ook in 10.52.9.0/24. Het verkeer snapt dus dat het normaliter naar buiten wil, behalve bij 10.*, dan moet het naar de 2e gateway op *.254.

Ik heb ook een VPN server werkend gekregen, zowel via L2TP als PPTP, maar beide varianten hebben het probleem dat je wel binnen komt, de USG zelf 10.52.9.253 kan pingen, het WAN prima kan gebruiken voor al het verkeer wat naar het internet gaat, maar om de een of andere reden weigert het lokale netwerk te benaderen (printers binnen 10.52.9.* kunnen niet benaderd worden) of überhaupt het 10.* verkeer te routeren naar de 2e gateway op *.254


Wat ik al gevonden of geprobeerd heb
Ik kan 10.52.9.253 bereiken, dus het moet een routeer probleem zijn, zodra je van buiten komt weet de USG niet meer welke gateway er gebruikt moet worden en probeert hij vermoedelijk alles over de WAN poort te sturen (die werkt wel), maar het interne netwerk werkt niet.

[SVMartin]

Ik ken de usg niet, maar meestal zitten vpn clients in een eigen vlan en moet je nog een firewall regel toevoegen om de vpn clients toegang te geven tot het corporate netwerk. Zou het dat kunnen zijn? Zie je in de firewall logs een deny/reject?

[nelizmastr]

Doorgaans wil je inderdaad je VPN gebruikers in een eigen subnet parkeren en dat subnet moet je dan ook een statische route meegeven naar het corporate LAN en dat met firewall regels afregelen c.q. toegang verlenen.

[jadjong]

Wat is het VPN-ip?

[Galileo_Galilei]

De VPN zit in 192.168.120.*, dat is dus een heel ander subnet als het corporate netwerk.

Er is een statische route van 10.* die naar de gateway gaat, alleen die lijkt hij dus niet te pakken. Wel is de LAN poort van het netwerk te pingen (die op de USG zelf).

Ik zie geen firewall regels die iets blokkeren, ik heb daarna ook nog firewall regels aangemaakt die expliciet een accept doen vanaf het 192.168 IP adres LAN in LAN out

[Tusk]

@Galileo_Galilei heb je dit al opgelost? Ik heb exact hetzelfde probleem. Bij 2 verschillende unifi netwerken. De VPN's zijn split tunneled. Ik dacht eerst dat het aan het ene netwerk lag, maar nu gebeurt het ook bij een ander netwerk.

Ik kan geen enkel remote netwerk pingen, en ook de USG zelf niet.

tunnel ip: 10.10.15.0/24
remote lan ip: 10.10.150/24
usg ip: 192.168.1.1

Wat ik al gedaan heb een static route gemaakt:

route add 10.10.50.0 mask 255.255.255.0 10.10.15.1

en in powershell een vpn connection gemaakt:
Add-VpnConnectionRoute -ConnectionName "vpnnaam" -DestinationPrefix "10.10.50.0/24" –PassThru

[jadjong]

Galileo_Galilei schreef op donderdag 12 januari 2023 @ 20:24:
De VPN zit in 192.168.120.*, dat is dus een heel ander subnet als het corporate netwerk.

Er is een statische route van 10.* die naar de gateway gaat, alleen die lijkt hij dus niet te pakken. Wel is de LAN poort van het netwerk te pingen (die op de USG zelf).

Ik zie geen firewall regels die iets blokkeren, ik heb daarna ook nog firewall regels aangemaakt die expliciet een accept doen vanaf het 192.168 IP adres LAN in LAN out

VPN client heeft IP 192.168.120.100
Er komt een pakketje binnen op de router van 192.168.120.100, bedoeld voor 10.52.9.100. Dat gaat goed omdat de USG een route heeft van 192* naar 10.*. Echter de LAN client met ip 10.52.9.100 heeft geen route voor het beantwoorden van pakketjes naar 192. Die gaan naar de default gateway en dat is niet je USG waar de VPN client op binnen komt.
Ergens moet je er nog voor zorgen dat verkeer vanuit LAN een weg naar 192 van de VPN weet te vinden.

Geldt mogelijk ook voor @Tusk

[nelizmastr]

Zonder gebruik van dynamische routingprotocollen geldt idd bovenstaande. Routes worden niet zomaar tussen de routers geleerd en moeten beide kanten op beide routers bestaan.