Shit, jeg er helt skeløjet efter at have brugt det meste af dagen på at prøve at få en VPN-gateway til at opføre sig ordentligt, og jeg mangler stadig at få den til at route trafik korrekt fra ydersiden til hosts på indersiden 😵‍💫

[nerdd@mstdn.social]

@klgn Hvis mine toots kan boostes, er det alti’ alti' ok at booste

[gunnar@social.lol]

@nerdd ikke en strongswan troldkarl, men sidste gang jeg lavede noget lignende (med wireguard) så skulle jeg slå ip forwarding til på debian serveren (net.ipv4.ip_forward) og så skal der være noget “iptables forward accept” i updown scriptet. Håber det hjælper og at en rigtig troldkarl kommer snart

[pmakholm@social.data.coop]

@nerdd Du har husket at slå forwarding til på serveren?

https://docs.strongswan.org/docs/latest/howtos/forwarding.html#_forwarding_client_traffic

Kender ikke til Strongswan, men det er absolut den fejl jeg ville lave.

[pmakholm@social.data.coop]

@nerdd I øvrigt ville jeg først som sidst køre en tcpdump på klient, vpn gateway og host bag vpn for at se hvor langt pakker kommer.

[nerdd@mstdn.social]

@gunnar Er et updown script noget, der bliver eksekveret, når en klient opretter forbindelse og afbryder? `net.ipv4.ip_forward` har jeg husket

[kramse@helvede.net]

@klgn @nerdd @holsta

Det er jo noget der kan bringes til at virke, men ofte vil jeg starte med at anbefale Wireguard istedet

Men fortæl gerne hvad vejledning du har fulgt.

[nerdd@mstdn.social]

@pmakholm `net.ipv4.ip_forward = 1` har jeg husket. tcpdump må jeg give et skud. Det interessante er, at jeg kan pinge gatewayens interne ip, men jeg kan ikke ssh’e til den, selv om sshd lytter på både den eksterne og interne ip. Andre hosts på netværket kan jeg ikke nå med pings.

[reynir@social.data.coop]

@gunnar @nerdd jeg tror man plejer at mene et script når et interface (virtuelt eller ej) kommer op eller ned.

[pmakholm@social.data.coop]

@nerdd Hvis du kan pinge men ikke ssh'e gatewayen, så tænker jeg umiddelbart firewall.

Der er jeg nok for rusten af bare at have brugt noget simpelt ufw. Så hvordan du debugger det, er jeg ikke helt sikker på.

Alternativet, som jeg ville se efter med tcpdump, er noget routing. For eksempel hvis jeg kunne se at der kom en ssh pakke frem til en host på indersiden og sshd sendte en svar-pakke, men den ikke kom frem til gatewayen.

[gunnar@social.lol]

@reynir @nerdd Præcis. I config filen til wireguard kan man sæt ind en path til “postup” og “postdown” scripts hvor man kan tilføj og fjern iptables regler blandt andet. Jeg så at strongswan har noget som kaldes updown i relation til ip forwarding.

[nerdd@mstdn.social]

@kramse Jeg er i gang med at flytte et gammelt setup fra Digital Ocean til Hetzner, så jeg har egentlig bare oversat en eksisterende /etc/ipsec.conf til /etc/swanctl/swanctl.conf. I sin tid brugte jeg https://www.digitalocean.com/community/tutorials/how-to-set-up-an-ikev2-vpn-server-with-strongswan-on-ubuntu-18-04-2, men skippede punkt 6, fordi vi brugte den eksterne firewall hos Digital Ocean.

@klgn @holsta

[nerdd@mstdn.social]

@pmakholm Det eneste, jeg har af firewall kørende på gatewayen er iptables, hvor der bliver tilføjet et par “forward accept” regler mellem de virtuelle ip'er og subnettet på indersiden, når klienter opretter en forbindelse: En regel hvor virtuel ip er source og subnet destination og en regel, hvor det er omvendt.

[nerdd@mstdn.social]

@gunnar @reynir Yes, jeg fandt frem til et standard script, som jeg har tilføjet nu, og det opretter to forward accept regler, hvor den virtuel ip og det interne subnet er source/destination. Desværre har det ikke hjulpet noget.

[nerdd@mstdn.social]

@pmakholm Hm, når jeg prøver at ssh'e til 10.135.0.3, som er gatewayens interne ip, og jeg lytter på det interface med tcpdump, ser jeg pakker med “10.10.10.1.58571 > 10.135.87.234.ssh”. 10.135.87.234 virker sært, synes jeg.

[nerdd@mstdn.social]

Hm, jeg har gravet mere i det.

Jeg opretter en VPN-forbindelse til gatewayen og får ip 10.10.10.1, og så kan jeg pinge gatewayens interne IP (10.135.0.3), og når jeg bruger tcpdump på det eksterne interface, ser jeg pakkerne. Når jeg pinger en anden host, ser jeg dem også, men det kan jeg i tcpdump på den anden host.

Når jeg så prøver at ssh’e til gatewayens interne ip, ser jeg dette:

"IP 10.10.10.1.58785 > 10.135.87.234.ssh”

Hvad pokker går 10.135.87.234 ud på?

[nerdd@mstdn.social]

Ooooog nu gik der en prås op for Rasmus!

10.135.87.234 er den interne ip på VPN'en ved den udbyder, jeg er ved at flytte væk fra, og jeg havde i min lokale ~/.ssh/config flg. stående:

Host 10.135.* !10.135.87.234
ProxyJump 10.135.87.234

Når jeg opdaterer det til:

Host 10.135.* !10.135.0.3
ProxyJump 10.135.0.3

Så virker det hele!

[nerdd@mstdn.social]

Tak til @klgn, @pmakholm, @gunnar, @reynir og @kramse for hjælp og indspark!

[infonauten@helvede.net]

@nerdd nogle gange hjælper det bare at skrive det. Så får hjernen vendt det igen. Fedt at du fik det løst!

[klgn@expressional.social]

@nerdd @pmakholm @gunnar @reynir @kramse Sådan. Stærkt klaret

[nerdd@mstdn.social]

@infonauten Det hjælper også at kigge på ip’en, jeg bruger, når jeg ssh'er til den gamle VPN

Det er ubeskriveligt fedt. Nu kan jeg komme videre med at flytte resten af kundens setup.