Verkeer door Site-to-Site werkt gedeeltelijk

[c-nan]

Host met VM's: Server-A
Heeft een fysieke interface: eno2
Heeft een virtuele bridge interface: br0 IP 85.17.1.1 + 10.0.0.1

VM op Server-A: VPN
Heeft een fysieke interface: enp1s0 IP 85.17.1.10 + 10.0.0.10

VM op Server-A: docker
Heeft een fysieke interface: enp1s0 10.0.0.200

Thuis heb ik een router: EdgeRouter
Heeft een lokaal netwerk: 192.168.1.0/24
Heeft een Site-to-Site VPN met VM VPN.
Left: 192.168.1.0/24
Right: 10.0.0.0/24

Vanuit huis kan ik dus pingen naar 10.0.0.1 en naar 10.0.0.10, maar pingen naar 10.0.0.200 werkt niet.

Bij een ping vanuit een client thuis naar Server-A/10.0.0.1 moet dit de route zijn:
Client thuis (192.168.1.40) -> EdgeRouter (192.168.1.1) -> VM VPN (10.0.0.10) -> Server-A (10.0.0.1).

Op Server-A heb ik een route:
192.168.1.0/24 via 10.0.0.10

Terugverkeer is dus:
Server-A (10.0.0.1) -> VM VPN (10.0.0.10) -> EdgeRouter (192.168.1.1) -> Client thuis (192.168.1.40)

Waarom werkt het pingen naar 10.0.0.200 niet?
Een tcpdump (tcpdump -i any icmp -nn) op VM VPN laat zien dat het verkeer op de VPN server aankomt (inkomend verkeer is dus te zien, maar uitgaand niet, hier lijkt het packet dus kwijt te geraken).
Een tcpdump op de docker VM laat ook zien dat het verkeer aankomt en er gaat zelfs verkeer terug.

De docker VM heeft een default route naar 10.0.0.1 (Server-A). Met tcpdump zie je dat het verkeer hier ook gewoon langsgaat (zowel heen als terug).

De route wat afgelegd wordt is dus als het goed is:
Client thuis (192.168.1.40) -> EdgeRouter (192.168.1.1) -> VM VPN (10.0.0.10) -> VM docker (10.0.0.200).
Terugverkeer zou dan moeten zijn:
VM docker (10.0.0.200) -> Server-A (10.0.0.1) -> VM VPN (10.0.0.10) -> EdgeRouter (192.168.1.1) -> Client thuis (192.168.1.40)

Maar het houd dus op bij VM VPN (10.0.0.10). Deze krijgt het verkeer doorgestuurd vanuit Server-A maar lijkt er niks mee te doen.

[nelizmastr]

En als je vanaf de andere kant pingt?

Er moet ook een route bestaan van 10.0.0.0/24 naar 192.168.1.0/24, anders klopt je return path inderdaad niet.

Doe ook een traceroute van de andere kant (vanaf de docker machine dus) om te zien of hij überhaupt over de tunnel terug komt.

[c-nan]

nelizmastr schreef op zaterdag 29 juli 2023 @ 21:39:
En als je vanaf de andere kant pingt?

Er moet ook een route bestaan van 10.0.0.0/24 naar 192.168.1.0/24, anders klopt je return path inderdaad niet.

Doe ook een traceroute van de andere kant (vanaf de docker machine dus) om te zien of hij überhaupt over de tunnel terug komt.

docker (10.0.0.200) pingen naar client thuis (192.168.1.40) werkt gewoon.

[nelizmastr]

c-nan schreef op zaterdag 29 juli 2023 @ 21:44:
[...]

docker (10.0.0.200) pingen naar client thuis (192.168.1.40) werkt gewoon.

Toevallig firewall aanstaan op de VM waar je docker op draait? Blokkeert die toevallig ping? Wel te pingen van een ander apparaat binnen het 10.0.0.0/24 subnet?

[c-nan]

nelizmastr schreef op zaterdag 29 juli 2023 @ 21:49:
[...]


Toevallig firewall aanstaan op de VM waar je docker op draait? Blokkeert die toevallig ping? Wel te pingen van een ander apparaat binnen het 10.0.0.0/24 subnet?

Geen firewall (ja wel, maar gestopt om te testen). Pingen vanuit 10.0.0.0/24 gaat gewoon goed.

[UTPBlokje]

Je vm vpn heeft ook een gateway. Deze kan de docker niet benaderen omdat je in de docker de gateway op de vm vpn hebt gezet. Dit is op te lossen om door op de gateway die de vm vpn gebruikt de 192.168.1.0/24 next hop de 10.0.0.10 te geven.

Tenminste dat zijn aannames aangezien er niet gedeeld wordt wat de vm voor os draait en functie heeft. Ook niet hoe de overige netwerk instellingen staan. Denk aan firewall regels op de routers

[c-nan]

UTPBlokje schreef op zaterdag 29 juli 2023 @ 22:39:
Je vm vpn heeft ook een gateway. Deze kan de docker niet benaderen omdat je in de docker de gateway op de vm vpn hebt gezet. Dit is op te lossen om door op de gateway die de vm vpn gebruikt de 192.168.1.0/24 next hop de 10.0.0.10 te geven.

Tenminste dat zijn aannames aangezien er niet gedeeld wordt wat de vm voor os draait en functie heeft. Ook niet hoe de overige netwerk instellingen staan. Denk aan firewall regels op de routers

De VM VPN kan de docker wel benaderen, ze zitten immers in hetzelfde subnet.

De VM VPN weet trouwens hoe het verkeer naar 192.168.1.0/24 moet lopen.

code:

[root@vpn ~]# ip xfrm policy
src 10.0.0.0/24 dst 192.168.1.0/24 
    dir out priority 375423 ptype main 
    tmpl src 85.17.1.10 dst 83.86.1.10
        proto esp spi 0xcb577d2f reqid 1 mode tunnel
src 192.168.1.0/24 dst 10.0.0.0/24 
    dir fwd priority 375423 ptype main 
    tmpl src 83.86.1.10 dst 85.17.1.10
        proto esp reqid 1 mode tunnel
src 192.168.1.0/24 dst 10.0.0.0/24 
    dir in priority 375423 ptype main 
    tmpl src 83.86.1.10 dst 85.17.1.10
        proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 ptype main 
src ::/0 dst ::/0 
    socket in priority 0 ptype main 
src ::/0 dst ::/0 
    socket out priority 0 ptype main 
src ::/0 dst ::/0 
    socket in priority 0 ptype main 
src ::/0 dst ::/0 
    socket out priority 0 ptype main 
[root@vpn ~]#

[jadjong]

Je hebt asynchrone routing. Vanaf de client ga je 192.168.1.40 > 192.168.1.1 > 10.0.0.10 > 10.0.0.200. Terug ga je 10.0.0.200 > 10.0.0.1 > 10.0.0.10 > 192.168.1.1 > 192.168.1.40

https://www.networkstraining.com/what-is-asymmetric-routing/

[c-nan]

jadjong schreef op zaterdag 29 juli 2023 @ 23:00:
Je hebt asynchrone routing. Vanaf de client ga je 192.168.1.40 > 192.168.1.1 > 10.0.0.10 > 10.0.0.200. Terug ga je 10.0.0.200 > 10.0.0.1 > 10.0.0.10 > 192.168.1.1 > 192.168.1.40

https://www.networkstraining.com/what-is-asymmetric-routing/

Dat ik dat heb had ik al door, maar werkt dat dan niet? Zo zit het hele internet aan elkaar geknoopt toch.

[jadjong]

c-nan schreef op zaterdag 29 juli 2023 @ 23:02:
[...]

Dat ik dat heb had ik al door, maar werkt dat dan niet? Zo zit het hele internet aan elkaar geknoopt toch.

Het kan werken. Wat zegt de log van de Edgerouter NAT/firewall?

[nelizmastr]

jadjong schreef op zaterdag 29 juli 2023 @ 23:18:
[...]

Het kan werken. Wat zegt de log van de Edgerouter NAT/firewall?

Idd interessant. Verschillende vendoren gaan er verschillend mee om.

Bij bijv. Fortigates wordt het verkeer bij een ander return pad gedropt in de basis en alleen geaccepteerd als het verkeer beide kanten op dezelfde route aflegt. Uiteraard zijn daar oplossingen voor, zal hier ook zo zijn.

[jadjong]

Op zich is het geen probleem zolang er geen firewall tussen zit. Op de WAN interface knikkert die Edgerouter namelijk alles wat niet tot het interne subnet behoort over de schutting bij een router van de ISP. Die doet er iets mee en krijgt data terug, voor de Edgerouter is het onbekend wat er op internet gebeurd (ding doet geen BGP) en die ziet alleen dat data aangeboden bij de ISP router ook weer terug komt via de ISP router.
In geval van deze VPN constructie is er geen upstream router in het spel. De VPN VM (10.0.0.10) en de twee andere servers behoren namelijk tot een en hetzelfde subnet, de Edgerouter is dus in de veronderstelling dat die met alle drie direct kan communiceren. Als er dan pakketjes naar x.200 gaan en die terug komen via x.1 dan is dat raar. Waarom het pingen vanaf x.200 naar 192.x wel werkt is simpel, de Edgerouter ziet een pakketje van x.200 via x.1 en knikkert de reply op dezelfde manier weer terug. Dat de terugweg direct kan in plaats van via x.1 is voor de firewall niet belangrijk, daar is het pakketje in beide richtingen immers al doorheen.

Wat je kan doen om dit op te lossen:
Edgerouter anders configureren zodat verkeer niet gedropt wordt (geen idee of die setting er in zit)
Tussenliggend subnet voor VPN instellen met aan beide kanten een router
VPN verplaatsen naar 10.0.0.1 host
Regel in de Edgerouter instellen dat heel 10.0.0.0/24 bereikbaar is via 10.0.0.1. Maar dat is een beetje tricky omdat de Edgerouter het hele subnet al kan bereiken.