3
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):
So wie ich es verstanden habe, bewirkt die Zeile
dass alle LAN Schnittstellen den VPN Tunnel nutzen, wenn eine IKEv2 Verbindung aktiviert wird.
Diese iptables Regel würde ich gerne ändern:
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:
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
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
;;
esacSo 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" Diese iptables Regel würde ich gerne ändern:
iptables -t nat -F postrouting_wan_ruleOb 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 ACCEPTJetzt 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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 526817
Url: https://administrator.de/contentid/526817
Printed on: April 23, 2024 at 23:04 o'clock
3 Comments
Latest comment
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 ...
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
dass alle LAN Schnittstellen den VPN Tunnel nutzen, wenn eine IKEv2 Verbindung aktiviert wird.
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" 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:
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.iptables -t nat -A postrouting_wan_rule -m policy --dir out --pol ipsec -j ACCEPTJetzt 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.
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
.
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
.
