OpenWrt Router und IPsec iptables
Hallo.
Ich weiß nicht ob das der richtige Ort für dieses Thema ist. Falls nicht, kann ein Administrator dieses Thema in den richtigen Bereich verschieben?
Gibt es hier jemand im Forum, der sich ein wenig mit der OpenWrt-Firewall auskennt und bei IPsec iptables gegen Bezahlung helfen kann? Mit den iptables wollte ich den Traffic der nicht zu IPsec gehört blockieren und nur den IPsec Traffic durchlassen.
Meldet euch bitte über eine Private Nachricht.
Vielen Dank.
Grüße
Achim
Edit: Falls es eine Lösung gibt, dann wäre die für mich (privat). Die Lösung wollte ich aber auch im OpenWrt Forum veröffnetlichen.
Ich weiß nicht ob das der richtige Ort für dieses Thema ist. Falls nicht, kann ein Administrator dieses Thema in den richtigen Bereich verschieben?
Gibt es hier jemand im Forum, der sich ein wenig mit der OpenWrt-Firewall auskennt und bei IPsec iptables gegen Bezahlung helfen kann? Mit den iptables wollte ich den Traffic der nicht zu IPsec gehört blockieren und nur den IPsec Traffic durchlassen.
Meldet euch bitte über eine Private Nachricht.
Vielen Dank.
Grüße
Achim
Edit: Falls es eine Lösung gibt, dann wäre die für mich (privat). Die Lösung wollte ich aber auch im OpenWrt Forum veröffnetlichen.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 548488
Url: https://administrator.de/forum/openwrt-router-und-ipsec-iptables-548488.html
Ausgedruckt am: 26.04.2025 um 07:04 Uhr
37 Kommentare
Neuester Kommentar

iptables -A FORWARD -s 10.0.0.0/24 -m policy --dir out --pol ipsec -j ACCEPT
iptables -A FORWARD -m policy --dir in --pol ipsec -j ACCEPT
iptables -A FORWARD -j DROP
iptables kann man übrigens schön in einer VM selbst zuhause üben ... es braucht nur RTFM
Falls nicht, kann ein Administrator dieses Thema in den richtigen Bereich verschieben?
Aus gutem Grund kannst nur DU als Threadowner das selber machen !!FAQs lesen hilft wirklich !
IPsec ist UDP 500 (IKE) und UDP 4500 (NAT Traversal) sowie das ESP Protokoll. Diese 3 Protokollkomponenten musst du zulassen auf die WAN IP des OpenWRT Routers.

Mit und ohne "-s 10.0.0.0/24" klappte die Verbindung nicht.
Tja, hättest du mal zumindest im Manual nachgeschlagen was der Parameter -s bedeutet dann hättest du sehen können das damit das Quellsubnet gemeint ist und du das selbstredend an dein LAN anpassen musst!!Aber hier scheint ja keiner mehr fähig zu sein die einem geposteten Links zumindest im Ansatz mal zu lesen und zu verstehen was die Optionen bedeuten. Minimal damit beschäftigen muss sich jeder, blind kopieren bringt dir nichts.

Mach dir erst mal klar welche deiner CHAIN oben dafür zuständig für die Weiterleitung von Traffic ist, generell ist das erst mal die FORWARDING Chain. Da OpenWRT hier zur übersichtlicheren Verwaltung neue CHAINs für die jeweiligen Netzbereiche anlegt ist in dem Fall die CHAIN zone_lan_forward dafür zuständig, in diese verzweigen ja die Regeln aus deinem LAN. Also gehören Regeln für zugelassenen und gesperrten Traffic dort hinein s.o.
Ohne ein grundlegendes Verständnis von iptables wird das schwer dir das hier näher zu bringen.
Ohne ein grundlegendes Verständnis von iptables wird das schwer dir das hier näher zu bringen.

Also für dich habe ich das mal in einer OpenWRT VM Instanz nachgebaut.
Aufbau der OpenWRT VM:(Verwendet wurde das aktuelle Image OpenWrt 19.07.1 r10911-c155900f66 / LuCI openwrt-19.07):
IPSec Ziel war eine pfSense VM
Auf dem OpenWRT wurde das IPSec mit der pfSense als strongswan-Site2Site VPN auf der Konsole konfiguriert und hergestellt.
Verbindung steht also zwischen den Subnetzen 192.168.16.0/24 <=> 192.168.50.0/24.
Dann auf dem OpenWRT erst einmal folgende NAT Regel hinzugefügt die dazu dient das Traffic innerhalb des VPNs nicht geNATed wird
Dann folgen zwei Traffic-Regeln die Traffic zwischen den LAN-Subnetzen der beiden Standorte möglich wird (die bestehenden Regeln habe ich der Übersicht hier nur ausgeblendet):
Abschließend noch die Zoneneinstellungen der Firewall so angepasst das sonstiger Traffic der nicht für das VPN Subnetz bestimmt ist verboten wird
Abschließender erfolgreicher Test von einer VM im LAN des OpenWrt mit Ping auf Google und an das VPN Subnetz der Gegenseite:
Google schlägt wie erwartet durch den generellen reject der Zone fehl, wohingegen der Traffic an das per VPN verbundene Subnetz weiterhin funktioniert, da die entsprechenden Traffic-Regeln zischen den VPN Subnetzen als Ausnahme agieren.
Case closed.
Aufbau der OpenWRT VM:(Verwendet wurde das aktuelle Image OpenWrt 19.07.1 r10911-c155900f66 / LuCI openwrt-19.07):
- Interface WAN 192.168.1.8/24
- Interface LAN 192.168.16.1/24
IPSec Ziel war eine pfSense VM
- Interface WAN 192.168.1.220/24
- Interface LAN 192.168.50.1/24
Auf dem OpenWRT wurde das IPSec mit der pfSense als strongswan-Site2Site VPN auf der Konsole konfiguriert und hergestellt.
Verbindung steht also zwischen den Subnetzen 192.168.16.0/24 <=> 192.168.50.0/24.
Dann auf dem OpenWRT erst einmal folgende NAT Regel hinzugefügt die dazu dient das Traffic innerhalb des VPNs nicht geNATed wird
Dann folgen zwei Traffic-Regeln die Traffic zwischen den LAN-Subnetzen der beiden Standorte möglich wird (die bestehenden Regeln habe ich der Übersicht hier nur ausgeblendet):
Abschließend noch die Zoneneinstellungen der Firewall so angepasst das sonstiger Traffic der nicht für das VPN Subnetz bestimmt ist verboten wird
Abschließender erfolgreicher Test von einer VM im LAN des OpenWrt mit Ping auf Google und an das VPN Subnetz der Gegenseite:
Google schlägt wie erwartet durch den generellen reject der Zone fehl, wohingegen der Traffic an das per VPN verbundene Subnetz weiterhin funktioniert, da die entsprechenden Traffic-Regeln zischen den VPN Subnetzen als Ausnahme agieren.
Case closed.

Zitat von @Achim462:
Erstaunlich wie du das hingekriegt hast. Und das sogar über eine VM mit OpenWrt. Ich scheitere schon bei der Umsetzung.
Naja, das ist ja die leichteste Übung, VM erstellen, mit LiveCD booten, x86 OpenWRT Image runterladen, entpacken und mit dd auf die Platte klöppeln, VM Booten, fertig Erstaunlich wie du das hingekriegt hast. Und das sogar über eine VM mit OpenWrt. Ich scheitere schon bei der Umsetzung.
Könntest du bitte nochmal versuchen eine IPsec/IKEv2 Verbindung aufzubauen, wenn ich dir ein 3 Tage Testaccount von einem VPN Anbieter gebe?
VPN Anbieter??? Du meinst also die ganzen Schnorchel-Anbieter die deinen Traffic abschnüffeln? Na dann brauchst du den ganzen Schmuh gar nicht, da reicht es das Default-GW auf den Tunnel zu legen (0.0.0.0/0 als Netz in Phase 2), schon hast du das gewünschte und alles läuft per Default über den Tunnel.Die Details zu der strongSwan Konfiguration zu einem bestimmten VPN Anbieter würde ich lieber in einer Privaten Nachricht besprechen.
Von solchen Anbietern lasse ich generell die Finger! Macht keinen Unterschied ob ich dazu ne pFSense als Gegenstelle nutze oder was anderes.Private Anfragen sind bei mir nicht umsonst und werden nur nach Tarif abgerechnet.
Die Details zu der strongSwan Konfiguration
Findet man auch hier:IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
bzw. Grundlagen auch hier:
IPsec IKEv2 Standort VPN Vernetzung mit Cisco, pfSense OPNsense und Mikrotik
Bei OpenWRT muss man teils sehr aufpassen bei VPN Verbindungen, denn in der Regel NATen die Router den VPN Traffic im Tunnel was zu erheblichen Problemen führen kann. Siehe dazu auch hier:
Problem mit site 2 site VPN

Zitat von @aqui:
Bei OpenWRT muss man teils sehr aufpassen bei VPN Verbindungen, denn in der Regel NATen die Router den VPN Traffic im Tunnel was zu erheblichen Problemen führen kann. Siehe dazu auch hier:
Problem mit site 2 site VPN
Hab ich ihm oben bereits mit der passenden Ausnahme im Postrouting gezeigt ...Bei OpenWRT muss man teils sehr aufpassen bei VPN Verbindungen, denn in der Regel NATen die Router den VPN Traffic im Tunnel was zu erheblichen Problemen führen kann. Siehe dazu auch hier:
Problem mit site 2 site VPN
<OT> Sorry, hatte ich glatt überlesen..
Kurze Frage dazu:
Ich habe das auf einem GL.inet OpenWRT System gemacht aber bemerkt das nach einem Reboot das über das GUi abgeschaltete Tunnel NAT wieder aktiv ist
Ist das normal so bei OpenWRT oder kann es sein das in dem spezifischen Router Modell ein Startup Script werkelt was das wieder aktiviert ? </OT>
Ich habe das auf einem GL.inet OpenWRT System gemacht aber bemerkt das nach einem Reboot das über das GUi abgeschaltete Tunnel NAT wieder aktiv ist
Ist das normal so bei OpenWRT oder kann es sein das in dem spezifischen Router Modell ein Startup Script werkelt was das wieder aktiviert ? </OT>

Zitat von @aqui:
Kurze Frage dazu:
Ich habe das auf einem GL.inet OpenWRT System gemacht aber bemerkt das nach einem Reboot das über das GUi abgeschaltete Tunnel NAT wieder aktiv ist
Ist das normal so bei OpenWRT oder kann es sein das in dem spezifischen Router Modell ein Startup Script werkelt was das wieder aktiviert ? </OT>
Kann ich hier mit dem neuesten OpenWRT Build (s. oben) zumindest nicht nachvollziehen, die Einstellung überlebt auch einen Reboot problemlos, was da sonst noch für Pakete auf deinem speziellen Gerät werkeln kann ich von hier aus nicht sagen. Manche vergessen aber gerne mal auf Save/Apply zu drücken und abzuwarten Kurze Frage dazu:
Ich habe das auf einem GL.inet OpenWRT System gemacht aber bemerkt das nach einem Reboot das über das GUi abgeschaltete Tunnel NAT wieder aktiv ist
Ist das normal so bei OpenWRT oder kann es sein das in dem spezifischen Router Modell ein Startup Script werkelt was das wieder aktiviert ? </OT>
Ich würde die Config nach dem Setzen im GUI noch mal auf der Konsole mit
iptables -t nat -L zone_wan_postrouting -v
Das mit dem CLI Kommando ist ein guter Tip, das hatte ich bis dato noch nicht gemacht und werde damit mal mein Glück versuchen.
Das GL.inet/OpenWRT Teil ist der klassische "Mango"_Router
Das GL.inet/OpenWRT Teil ist der klassische "Mango"_Router

Vielleicht hat der sich ja das neue Corona-Virus eingefangen bei der Farbe
.

Ein gewisses Vertrauen muss man aber schon haben.
Never trust anyone ... only what you checked yourself.Ein VPN Anbieter hat so seine Vorteile und Nachteile.
Nein, falsch !Öffentliche VPN Anbieter haben generell NUR Nachteile. Jedenfalls was die Vertraulichkeit angeht. Das die alle Userdaten weitergeben davon kannst du sicher ausgehen. Siehe der richtigen Bemerkung vom Kollegen @142970 oben !!
Kann es zwar aktuell nicht mit OpenWRT testen aber mit pfSense, Mikrotik und Cisco kommt die IPsec VPN Verbindung sofort zustande.

sondern mehr um die Konfiguration.
Die steht oben, nachmachen, fertig.
und wo 0.0.0.0/0?
Je nachdem was bei dir left und right subnet ist, wenn left die VPN Gegenstelle ist dannleft 37.48.94.1
leftsubnet 0.0.0.0/0
right 37.48.94.1
rightsubnet 0.0.0.0/0
Mit der Konfiguration habe ich schon seit Monaten zu kämpfen.
Du darfst auch gerne mal das Manual lesenhttps://wiki.strongswan.org/projects/strongswan/wiki/ConnSection
Wäre vielleicht mal ein Anfang statt monatelang nur rum zu eiern was in zwei Minuten erledigt ist

Du solltest meine Kommentare dazu oben genauer lesen, wie ich schrieb brauchst du die Regeln in deinem Fall dann nicht da bei einem Subnet von 0.0.0.0/0 alles was nicht lokal über die Routing-Tabelle angesprochen werden kann sowieso über den Tunnel geht, da ja 0.0.0.0/0 der Default-Route entspricht => Routing Grundlagen nur so nebenbei.
Meine Schilderung in der Anleitung war für den Fall das man ein "explizites" Subnetz über den Tunnel anspricht, das hattest du ja leider nicht in deinem Thread erwähnt.
Meine Schilderung in der Anleitung war für den Fall das man ein "explizites" Subnetz über den Tunnel anspricht, das hattest du ja leider nicht in deinem Thread erwähnt.
aber auf OpenWrt scheint das Ganze nicht so richtig zu funktionieren.
Das liegt vermutlich daran das du dafür noch ein VTI Support Package installieren musst denn von Haus aus kann OpenWRT das nicht.https://openwrt.org/packages/pkgdata_lede17_1/vti
https://openwrt.org/docs/guide-user/network/tunneling_interface_protocol ...
Mit dem entsprechenden vti Package also kein Problem.
Alternativ einen Mikrotik Router oder Cisco zu nehmen. Siehe dazu auch hier:
Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing
Cisco SVTI - Tunnel