StrongSwan IKEv2 Internetverkehr nur mithilfe iptables durchlassen

Hallo.

Ich konnte erfolgreich eine IKEv2 Verbindung herstellen und benötige eure Hilfe zu iptables auf einem OpenWRT Router. Die Erfahrung mit iptables liegt bei mir bei 0.

Im Moment verwende ich folgendes Skript (/etc/ipsec.user):

case "$PLUTO_VERB" in  
up-client)
        iptables -t nat -A postrouting_wan_rule -s 192.168.1.0/24 -m policy --dir out --pol none -j SNAT --to-source "$PLUTO_MY_SOURCEIP4_1"   
        ;;
down-client)
        iptables -t nat -F postrouting_wan_rule
        ;;
esac

So wie ich es verstanden habe, bewirkt die Zeile

 iptables -t nat -A postrouting_wan_rule -s 192.168.1.0/24 -m policy --dir out --pol none -j SNAT --to-source "$PLUTO_MY_SOURCEIP4_1"   

dass alle LAN Schnittstellen den VPN Tunnel nutzen, wenn eine IKEv2 Verbindung aktiviert wird.

Diese iptables Regel würde ich gerne ändern:

iptables -t nat -F postrouting_wan_rule

Es bewirkt, dass beim Deaktivieren der IKEv2 Verbindung die ISP IP angezeigt wird. Stattdessen würde ich gerne die iptables Regel durch eine ersetzen, die den ISP Verkehr blockiert, bis eine IKEv2 Verbindung wieder aufgebaut wurde.

Ob die folgende iptables Regel dafür geeignet ist und richtig oder falsch ist, kann ich nicht sagen. Auf jeden fall erfüllt es seine Aufgabe. Beim Beenden der IKEv2 Verbindung komme ich nicht ins Internet. Wenn IKEv2 Verbindung wieder aufgebaut wurde, dann wird die IKEv2 Server IP angezeigt. Hier die Regel:

iptables -t nat -A postrouting_wan_rule -m policy --dir out --pol ipsec -j ACCEPT

Bitte ändern, falls die falsch ist.

Jetzt fehlen mir die Standardregeln, die vor der IKEv2 Verbindung greifen sollen. Diese Regeln würden nach dem booten greifen, wenn man sie wahrscheinlich in "/etc/firewall.user" einträgt.
Es wäre nicht schlecht, wenn diese Regeln alles blockieren, bis eine IKEv2 Verbindung aufgebaut wurde.

Falls die Idee nicht umsetzbar ist, dann bin ich natürlich für alternative Vorschläge dankbar.

Grüße

John

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 526817

Url: https://administrator.de/forum/strongswan-ikev2-internetverkehr-nur-mithilfe-iptables-durchlassen-526817.html

Ausgedruckt am: 26.04.2025 um 09:04 Uhr

3 Kommentare

Neuester Kommentar

Du musst hier etwas aufpassen mit den Regeln. Alles in Richtung ISP darfst du keinesfalls blocken, denn dann funktionieren z.B. keinerlei DNS Auflösungen mehr usw. Wenn du also deine Tunnel Zieladresse per Hostname angibst gleichzeitig aber TCP/UDP 53 blockierst wirst du den Tunnel nie mehr aufbauen können.
Etwas überlegen beim Anlegen der Regeln ist also angebracht.
Deine iptables Regeln oben betreffen allesamt nur NAT, bestimmen also was über die Adress Translation geht und was nicht. Keine der aufgeführten Regeln blockiert irgendwelchen IP Traffic bezogen auf Ports oder Protokolloptionen. IKEv2 besteht aus UDP 500, UDP 4500 und dem ESP Protokoll (Nummer 50). So eine Regel die nur rein diese Komponenten durchlässt ist oben nicht zu sehen.
Ggf. hilft etwas lesen der iptables Grundlagen:
https://www.hostinger.com/tutorials/iptables-tutorial
oder auch ein gutes Buch zu dem Thema.
https://www.amazon.de/s?k=iptables&__mk_de_DE=AMAZON&ref=nb_sb_n ...

Zitat von @John1293:
So wie ich es verstanden habe, bewirkt die Zeile

 iptables -t nat -A postrouting_wan_rule -s 192.168.1.0/24 -m policy --dir out --pol none -j SNAT --to-source "$PLUTO_MY_SOURCEIP4_1"   

dass alle LAN Schnittstellen den VPN Tunnel nutzen, wenn eine IKEv2 Verbindung aktiviert wird.

Nein! Diese Regel besagt das von jeglichem ausgehenden Traffic aus dem Subnetz 192.168.1.0/24 der nicht für den IPSec-Tunnel bestimmt ist per SRC-NAT die Absenderadresse geändert (geNATet) wird.

Hier die Regel:

iptables -t nat -A postrouting_wan_rule -m policy --dir out --pol ipsec -j ACCEPT

Diese Regel besagt das Traffic der für den Tunnel vorgesehen ist vom NAT ausgenommen wird, also dessen Adressen nicht umgeschrieben werden , nicht mehr und nicht weniger. Ist ja auch klar denn du willst ja nicht das zwischen den IPSec Clients immer die Firewall als Absender im Paket steht sondern du willst effektiv zwischen den Clients routen und nicht NATen.

Jetzt fehlen mir die Standardregeln, die vor der IKEv2 Verbindung greifen sollen.

Wie @aqui schon geschrieben hat UDP500/4500 und ESP(Protokoll Nr. 50), sind für den Responder I'm INPUT freizuschalten.

iptables Grundlagen aneignen dann bist du für deine Firewall Arbeiten gerüstet, ansonsten wird das ein Himmelfahrtskommando.

Vielen Dank für die ausführliche Antworten.

Ich kann also das Skript so stehen lassen und bräuchte nur noch die Standardregeln hinzuzufügen.

Also UDP500/4500 und ESP(Protokoll Nr. 50) für den Responder I'm INPUT und TCP/UDP 53 freigeben.

iptables Grundlagen aneignen dann bist du für deine Firewall Arbeiten gerüstet, ansonsten wird das ein Himmelfahrtskommando.

Mit einem Himmelfahrtskommando kann ich leben, weil ich ein handicap mit dem Langzeitgedächtnis habe. Für mich heißt es jetzt testen, testen und testen, bis es funktioniert