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 😵💫
-
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
-
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 det er simpelthen black voodoo
-
@nerdd det er simpelthen black voodoo
@klgn Fuldstændig! Jeg tror, mit problem handler om, at klienterne får virtuelle IP'er, som ikke er på samme subnet som ip'erne på netværket, så jeg skal muligvis lave noget NAT-halløj.
-
@klgn Fuldstændig! Jeg tror, mit problem handler om, at klienterne får virtuelle IP'er, som ikke er på samme subnet som ip'erne på netværket, så jeg skal muligvis lave noget NAT-halløj.
@nerdd uff, lyder ikke godt
-
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
Hvis jeg kender en Strongswan-troldkarl (M/K), kunne jeg godt bruge lidt hjælp.
Klienter (udenfor) får en virtuel IP fra et 10.10.10.0/24 subnet, og subnettet på indersiden er 10.135.0.0/16. Lige nu kan klienterne ikke få hul igennem til hosts på indersiden.
Skal jeg lave trylletricks med iptables for at klienter kan snakke med hosts?
-
Hvis jeg kender en Strongswan-troldkarl (M/K), kunne jeg godt bruge lidt hjælp.
Klienter (udenfor) får en virtuel IP fra et 10.10.10.0/24 subnet, og subnettet på indersiden er 10.135.0.0/16. Lige nu kan klienterne ikke få hul igennem til hosts på indersiden.
Skal jeg lave trylletricks med iptables for at klienter kan snakke med hosts?
-
@nerdd uff, lyder ikke godt
@klgn Det handler sikkert om et eller andet, der mangler i iptables. Som jeg har ca. nul forstand på
(tak for boost! 
) -
@klgn Det handler sikkert om et eller andet, der mangler i iptables. Som jeg har ca. nul forstand på
(tak for boost! )@nerdd kan sagtens være, mine networking skills kommer også til kort her.
Velbekomme, glad for, det var ok -
T tofticles@helvede.net shared this topic
-
@nerdd kan sagtens være, mine networking skills kommer også til kort her.
Velbekomme, glad for, det var ok@klgn Hvis mine toots kan boostes, er det alti’ alti' ok at booste
-
F folfdk@helvede.net shared this topic
-
Hvis jeg kender en Strongswan-troldkarl (M/K), kunne jeg godt bruge lidt hjælp.
Klienter (udenfor) får en virtuel IP fra et 10.10.10.0/24 subnet, og subnettet på indersiden er 10.135.0.0/16. Lige nu kan klienterne ikke få hul igennem til hosts på indersiden.
Skal jeg lave trylletricks med iptables for at klienter kan snakke med hosts?
@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
-
Hvis jeg kender en Strongswan-troldkarl (M/K), kunne jeg godt bruge lidt hjælp.
Klienter (udenfor) får en virtuel IP fra et 10.10.10.0/24 subnet, og subnettet på indersiden er 10.135.0.0/16. Lige nu kan klienterne ikke få hul igennem til hosts på indersiden.
Skal jeg lave trylletricks med iptables for at klienter kan snakke med hosts?
@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.
-
@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.
@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 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
@gunnar Er et updown script noget, der bliver eksekveret, når en klient opretter forbindelse og afbryder? `net.ipv4.ip_forward` har jeg husket
-
-
@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.
@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.
-
@gunnar Er et updown script noget, der bliver eksekveret, når en klient opretter forbindelse og afbryder? `net.ipv4.ip_forward` har jeg husket
