achim462
Goto Top

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.

Content-Key: 548488

Url: https://administrator.de/contentid/548488

Printed on: April 19, 2024 at 03:04 o'clock

Mitglied: 142970
142970 Feb 16, 2020 updated at 10:41:26 (UTC)
Goto Top
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
usw.

iptables kann man übrigens schön in einer VM selbst zuhause üben ... es braucht nur RTFM face-smile
Member: Achim462
Achim462 Feb 16, 2020 updated at 11:22:27 (UTC)
Goto Top
Entschuldigung das ich nicht genug Daten geliefert habe. Hier sind sie:

Openwrt4.png sind alle mögliche iptables Packages, die man hinzufügen kann.

openwrt1

openwrt2

openwrt3

openwrt4

Hier noch die die OpenWrt UCI Firewall:
config defaults
	option syn_flood '1'  
	option forward 'REJECT'  
	option input 'ACCEPT'  
	option output 'ACCEPT'  

config zone
	option name 'lan'  
	option input 'ACCEPT'  
	option output 'ACCEPT'  
	option forward 'ACCEPT'  
	option network 'lan'  

config zone
	option name 'wan'  
	option input 'REJECT'  
	option output 'ACCEPT'  
	option forward 'REJECT'  
	option masq '1'  
	option mtu_fix '1'  
	option network 'wan'  

config rule
	option name 'Allow-DHCP-Renew'  
	option src 'wan'  
	option proto 'udp'  
	option dest_port '68'  
	option target 'ACCEPT'  
	option family 'ipv4'  

config rule
	option name 'Allow-Ping'  
	option src 'wan'  
	option proto 'icmp'  
	option icmp_type 'echo-request'  
	option family 'ipv4'  
	option target 'ACCEPT'  

config rule
	option name 'Allow-IGMP'  
	option src 'wan'  
	option proto 'igmp'  
	option family 'ipv4'  
	option target 'ACCEPT'  

config rule
	option name 'Allow-DHCPv6'  
	option src 'wan'  
	option proto 'udp'  
	option src_ip 'fc00::/6'  
	option dest_ip 'fc00::/6'  
	option dest_port '546'  
	option family 'ipv6'  
	option target 'ACCEPT'  

config rule
	option name 'Allow-MLD'  
	option src 'wan'  
	option proto 'icmp'  
	option src_ip 'fe80::/10'  
	list icmp_type '130/0'  
	list icmp_type '131/0'  
	list icmp_type '132/0'  
	list icmp_type '143/0'  
	option family 'ipv6'  
	option target 'ACCEPT'  

config rule
	option name 'Allow-ICMPv6-Input'  
	option src 'wan'  
	option proto 'icmp'  
	list icmp_type 'echo-request'  
	list icmp_type 'echo-reply'  
	list icmp_type 'destination-unreachable'  
	list icmp_type 'packet-too-big'  
	list icmp_type 'time-exceeded'  
	list icmp_type 'bad-header'  
	list icmp_type 'unknown-header-type'  
	list icmp_type 'router-solicitation'  
	list icmp_type 'neighbour-solicitation'  
	list icmp_type 'router-advertisement'  
	list icmp_type 'neighbour-advertisement'  
	option limit '1000/sec'  
	option family 'ipv6'  
	option target 'ACCEPT'  

config rule
	option name 'Allow-ICMPv6-Forward'  
	option src 'wan'  
	option dest '*'  
	option proto 'icmp'  
	list icmp_type 'echo-request'  
	list icmp_type 'echo-reply'  
	list icmp_type 'destination-unreachable'  
	list icmp_type 'packet-too-big'  
	list icmp_type 'time-exceeded'  
	list icmp_type 'bad-header'  
	list icmp_type 'unknown-header-type'  
	option limit '1000/sec'  
	option family 'ipv6'  
	option target 'ACCEPT'  

config rule
	option name 'Allow-ESP-input'  
	option proto 'esp'  
	option target 'ACCEPT'  
	option src 'dmz'  
	option family 'ipv4'  

config rule
	option name 'Allow-IKE-input'  
	option dest_port '500 4500'  
	option proto 'udp'  
	option target 'ACCEPT'  
	option src 'dmz'  
	option family 'ipv4'  

config zone
	option network 'dmz'  
	option name 'dmz'  
	option input 'ACCEPT'  
	option forward 'ACCEPT'  
	option output 'ACCEPT'  
	option family 'ipv4'  

config rule
	option dest_port '53'  
	option src 'dmz'  
	option name 'dmz-dns'  
	option target 'ACCEPT'  
	list proto 'tcp'  
	list proto 'udp'  
	option family 'ipv4'  

config rule
	option src 'dmz'  
	option name 'dmz-dhcp'  
	option target 'ACCEPT'  
	list proto 'udp'  
	option dest_port '68'  
	option family 'ipv4'  

config forwarding
	option dest 'wan'  
	option src 'lan'  

config forwarding
	option dest 'wan'  
	option src 'dmz'  

config include
	option path '/etc/firewall.user'  

Grüße

Achim
Member: Achim462
Achim462 Feb 16, 2020 updated at 11:58:21 (UTC)
Goto Top
Hallo soccer.


Ich bin mit dem OpenWrt Router über LAN mit dem Desktop Computer verbunden. "iptables -A FORWARD -j DROP" blockiert zwar schön alles, aber es kommt kein IPsec Traffic durch. Ich nehme an das ich für 10.0.0.0/24 was anderes einsetzen muss?

Grüße

Achim

Edit: IPsec läuft auf OpenWrt. Hier die IPsec Konfiguration:
connections {
    lan-passthrough {
        children {
            lan-passthrough {
                local_ts = 192.168.1.0/24 # Replace with your LAN subnet
                remote_ts = 192.168.1.0/24 # Replace with your LAN subnet
                priority = 1
                mode = pass
                start_action = trap
            }
        }
    }
    pp {
        unique = never
        version = 2
        keyingtries=0
        dpd_delay = 300s
        rekey_time = 0
        encap = yes
        proposals = aes256-sha256-modp2048
        vips = 0.0.0.0
        send_cert = never
        send_certreq = yes
        local_addrs = 192.168.1.1 # Replace with your default Router IP address
        remote_addrs = <PP Server IP> # Replace with your PP Server IP

        local {
            id = 192.168.1.1 # Replace with your default Router IP address
            auth = eap-mschapv2
            eap_id = Username # Replace with your PP-Username
        }
        remote {
            id = %any
            auth = pubkey
        }
        children {
            pp {
                dpd_action = start
                close_action = start
                inactivity = 36000s
                life_time = 0
                esp_proposals = aes256-sha256
                updown = /etc/swanctl/updown.sh
                remote_ts = 0.0.0.0/0
                priority = 1
                mode = tunnel
                start_action = start # "none" is for manual start, or use "start" for autostart 
            }
        }
    }
} # connections
secrets {
    eap-user {
        id = Username # Replace with your PP-Username
        secret = "Password" # Replace with your "PP-Password"   
    }
} # secrets
Member: aqui
aqui Feb 16, 2020 updated at 13:13:12 (UTC)
Goto Top
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.
Member: Achim462
Achim462 Feb 16, 2020 at 14:04:05 (UTC)
Goto Top
Ich habe jetzt diese Regeln:

config rule
	option name 'Allow-ESP-input'  
	option proto 'esp'  
	option target 'ACCEPT'  
	option src 'dmz'  
	option family 'ipv4'  

config rule
	option name 'Allow-IKE-input'  
	option dest_port '500 4500'  
	option proto 'udp'  
	option target 'ACCEPT'  
	option src 'dmz'  
	option family 'ipv4'  

durch diese ersetzt:
config rule
	option name 'Allow-ESP-input'  
	option src 'wan'  
	option proto 'esp'  
	option target 'ACCEPT'  

config rule
	option name 'Allow-IKE-NATT-input'  
	option src 'wan'  
	option dest_port '500 4500'  
	option proto 'udp'  
	option target 'ACCEPT'  

Und dazu die iptables von soccer hinzugefügt. Zu Testzwecken habe ich mal "-s 10.0.0.0/24" enfernt.
Mit und ohne "-s 10.0.0.0/24" klappte die Verbindung nicht.
Mitglied: 142970
142970 Feb 16, 2020 updated at 14:13:53 (UTC)
Goto Top
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.
Member: Achim462
Achim462 Feb 16, 2020 at 14:38:18 (UTC)
Goto Top
Zitat von @142970:

Minimal damit beschäftigen muss sich jeder, blind kopieren bringt dir nichts.

Da stimme ich völlig zu. LAN Subnet habe ich davor auch schon ausprobiert.

Ich kann gerade Äpfel von Birnen unterscheiden. Deshalb bitte ich um Nachsicht.
Mitglied: 142970
142970 Feb 16, 2020 updated at 14:57:30 (UTC)
Goto Top
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.
Mitglied: 142970
142970 Feb 17, 2020 updated at 11:21:38 (UTC)
Goto Top
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):
  • 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.

screenshot

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

screenshot

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):

screenshot

Abschließend noch die Zoneneinstellungen der Firewall so angepasst das sonstiger Traffic der nicht für das VPN Subnetz bestimmt ist verboten wird

screenshot

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.

screenshot

Case closed.
Member: Achim462
Achim462 Feb 17, 2020 at 17:33:15 (UTC)
Goto Top
Hallo soccer.

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?

Die Details zu der strongSwan Konfiguration zu einem bestimmten VPN Anbieter würde ich lieber in einer Privaten Nachricht besprechen.

Grüße

Achim
Mitglied: 142970
142970 Feb 18, 2020 updated at 07:37:40 (UTC)
Goto Top
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 face-smile.
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.
Member: aqui
aqui Feb 18, 2020 updated at 10:32:53 (UTC)
Goto Top
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
Mitglied: 142970
142970 Feb 18, 2020 updated at 10:41:38 (UTC)
Goto Top
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 ...
Member: aqui
aqui Feb 18, 2020 at 10:52:45 (UTC)
Goto Top
<OT> Sorry, hatte ich glatt überlesen.. face-wink 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 face-sad
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>
Mitglied: 142970
142970 Feb 18, 2020 updated at 11:09:44 (UTC)
Goto Top
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 face-sad
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 face-wink.
Ich würde die Config nach dem Setzen im GUI noch mal auf der Konsole mit
iptables -t nat -L zone_wan_postrouting -v
gegenchecken, evt. gibt es da Berechtigungsprobleme oder ein zus. installiertes Package das das erledigt, oder die Macher von dem Device haben da was angepasst. Musst du dir in dem Fall wohl mal die Services und Packages auf der Konsole ansehen.
Member: aqui
aqui Feb 18, 2020 at 11:32:09 (UTC)
Goto Top
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 face-wink
Mitglied: 142970
142970 Feb 18, 2020 updated at 11:39:10 (UTC)
Goto Top
Zitat von @aqui:
Das GL.inet/OpenWRT Teil ist der klassische "Mango"_Router face-wink
Vielleicht hat der sich ja das neue Corona-Virus eingefangen bei der Farbe face-big-smile.
Member: aqui
aqui Feb 18, 2020 at 11:44:08 (UTC)
Goto Top
Ich hol besser schon mal den Mundschutz raus !!! face-big-smile
Member: Achim462
Achim462 Feb 18, 2020 updated at 11:54:22 (UTC)
Goto Top
Zitat von @142970:

VPN Anbieter??? Du meinst also die ganzen Schnorchel-Anbieter die deinen Traffic abschnüffeln?

Ja, ich weiß. Ein VPN Anbieter hat so seine Vorteile und Nachteile. Ein gewisses Vertrauen muss man aber schon haben.

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.

Ich weiß, dass es immer einen Haken gibt oder immer etwas dazwischen kommt, wenn ich etwas in Angriff nehme. Dem VPN Anbieter musst du auch nicht vertrauen. ;)

Private Anfragen sind bei mir nicht umsonst und werden nur nach Tarif abgerechnet.

Mit der Konfiguration habe ich schon seit Monaten zu kämpfen. Deshalb bin ich froh, dass es hier im Forum überhaupt Experten gibt, die davon Ahnung haben! Als Privatperson kann ich mir bis zu 100€ leisten.

Ich würde mich wirklich freuen, wenn du die Konfiguration mit einem bestimmten VPN Anbieter versuchen würdest.

Grüße

Achim
Mitglied: 142970
142970 Feb 18, 2020 updated at 12:03:45 (UTC)
Goto Top
Ein gewisses Vertrauen muss man aber schon haben.
Never trust anyone ... only what you checked yourself.
Member: aqui
aqui Feb 18, 2020 updated at 12:05:23 (UTC)
Goto Top
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.
Member: Achim462
Achim462 Feb 18, 2020 at 12:08:30 (UTC)
Goto Top
Wie auch immer. Ich würde es schön finden, wenn hier nicht über Vertraulichkeit von VPN Anbietern geschrieben wird, sondern mehr um die Konfiguration.

Mein Angebot steht, auch wenn es nicht viel ist.

Grüße

Achim
Mitglied: 142970
142970 Feb 18, 2020 at 12:13:43 (UTC)
Goto Top
sondern mehr um die Konfiguration.
Die steht oben, nachmachen, fertig.
Member: aqui
aqui Feb 18, 2020 updated at 12:18:37 (UTC)
Goto Top
Habs eben mal auf dem Mango Router (OpenWRT) und zugeladenem StrongSwan Package probiert. Auch da kam die IKEv2 VPN Verbindung von oben sofort zustande. Übrigens auch die mit Wireguard den die zum test anbieten. Der Mango Router kann WireGuard out of the Box.
Works as designed ! face-wink
Member: Achim462
Achim462 Feb 18, 2020 at 12:25:21 (UTC)
Goto Top
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)

Da muss ich schon nachfragen. Ich habe als Ziel die remote IP 37.48.94.1. Wo müsste ich in deinem Beispiel 37.48.94.1 eintragen und wo 0.0.0.0/0?

Sorry. Das sind bestimmt für dich soccer und für die anderen dumme Fragen, aber fragen kostet ja nichts.

Grüße

Achim
Mitglied: 142970
142970 Feb 18, 2020 updated at 12:37:01 (UTC)
Goto Top
und wo 0.0.0.0/0?
Je nachdem was bei dir left und right subnet ist, wenn left die VPN Gegenstelle ist dann
left 37.48.94.1
leftsubnet 0.0.0.0/0
oder eben
right 37.48.94.1
rightsubnet 0.0.0.0/0
wenn right die VPN Gegenstelle ist.


Mit der Konfiguration habe ich schon seit Monaten zu kämpfen.
Du darfst auch gerne mal das Manual lesen
https://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 face-wink.
Member: Achim462
Achim462 Feb 18, 2020 updated at 13:02:41 (UTC)
Goto Top
Natürlich steht in meiner strongSwan Konfiguration:

right 37.48.94.1
rightsubnet 0.0.0.0/0

Meine Frage beziehte sich mehr auf deine Konfiguration.

Du hast über LuCI 3 Regeln angelegt. Einmal "VPN NAT exlcude", "VPN IN" und "VPN OUT".

1) Reichen diese Regeln oder muss ich die iptables dazu nehmen.
2) Verstehe ich richtig, dass ich in deinem Beispiel statt 192.168.50.0/24 ich 0.0.0.0/0 nehmen muss?

Danke soweit für deine Geduld.

Grüße

Achim
Mitglied: 142970
142970 Feb 18, 2020 updated at 13:52:47 (UTC)
Goto Top
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.
Member: Achim462
Achim462 Feb 19, 2020 at 19:49:43 (UTC)
Goto Top
Zitat von @142970:

Du solltest meine Kommentare dazu oben genauer lesen,

Wenn man in vielen IT-Bereichen keine Grundlagen hat, so wie ich, dann versteht man es auch nicht.

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.

Das ergibt Sinn. Trotz der Erklärung kann ich nach wie vor 1+1 nicht zusammen zählen, um auf das Ergebnis zu kommen.
Anders Formuliert: Du hast mir schon sehr viele hilfreiche Tipps gegeben. Trotzdem kann ich die Tipps nicht umsetzen, um den sonstigen Traffic, der nicht zu IPsec gehört zu blockieren.

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.

Ich kann mich nur entschuldigen.

Grüße

Achim
Member: Achim462
Achim462 Feb 24, 2020 updated at 23:47:20 (UTC)
Goto Top
Hallo.

Ich habe die oberen Regeln von @142970 nochmal versucht.

Wenn ich es richtig verstehe, springen die Regeln "VPN OUT" und "VPN IN" dann ein, wenn bei den Zoneneinstellungen die Kette "Forward" auf "reject" steht und "wan" bei lan zu wan entfernt ist.
Also braucht man die Regeln "VPN NAT exclude", "VPN IN" und "VPN OUT", um näheres bei "wan" zu definieren. Hier hört mein Verständnis schon auf. Gibt es überhaupt eine Ziel mit Subnet bei einem VPN Anbieter? Was muss ich für "wan" eintragen?

Grüße

Achim
Member: Achim462
Achim462 Feb 25, 2020 at 15:09:06 (UTC)
Goto Top
Ich habe noch eine weitere Methode ausprobiert. Für den EdgeRouter gibt es eine strongSwan IPsec/IKEv2 Anleitung mit VTI Interface, aber auf OpenWrt scheint das Ganze nicht so richtig zu funktionieren.

Mit dem updown.sh Skript kommen zwar RX Pakete an, aber es werden keine TX Pakete übertragen. Siehe Bild:

vti

Hier ist das updown.sh Skript:
#!/bin/sh
set -o nounset
set -o errexit

# Interface
VTI_IFACE="vti0"  

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_SOURCEIP"  
	
	echo "Creating tunnel interface $VTI_IFACE local $PLUTO_ME remote $PLUTO_PEER mode vti key 42"  
	ip tunnel add "$VTI_IFACE" local "$PLUTO_ME" remote "$PLUTO_PEER" mode vti  
	echo "Activating tunnel interface $VTI_IFACE"  
	ip link set "$VTI_IFACE" up  

	echo "Adding $PLUTO_MY_SOURCEIP to $VTI_IFACE"  
	ip addr add "$PLUTO_MY_SOURCEIP" dev "$VTI_IFACE"  

	echo "Disabling IPsec policy (SPD) for $VTI_IFACE"  
	sysctl -w "net.ipv4.conf.$VTI_IFACE.disable_policy=1"  

	DEFAULT_ROUTE="$(ip route show default | grep default | awk '{print $3}')"  
	echo "Identified default route as $DEFAULT_ROUTE"  
	echo "Adding route: $PLUTO_PEER via $DEFAULT_ROUTE dev $PLUTO_INTERFACE"  
	ip route add "$PLUTO_PEER" via "$DEFAULT_ROUTE" dev "$PLUTO_INTERFACE"  
	;;
down-client)
	iptables -t nat -F postrouting_wan_rule

	echo "Deleting interface $VTI_IFACE"  
	ip tunnel del "$VTI_IFACE"  

	echo "Deleting route for $PLUTO_PEER"  
	ip route del "$PLUTO_PEER"  
	;;
esac

Es wäre natürlich schön, wenn es eine Lösung gebe. Dann wären einige Regeln in LuCI überflüssig.

Grüße

Achim
Member: aqui
aqui Feb 25, 2020 at 16:49:36 (UTC)
Goto Top
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
Member: Achim462
Achim462 Feb 25, 2020 at 20:14:14 (UTC)
Goto Top
Zitat von @aqui:

Mit dem entsprechenden vti Package also kein Problem.

Ich habe folgende Packages vorinstalliert gehabt:
opkg install strongswan-full ip-full vti kmod-ip-vti kmod-ip6-vti

Wenn das alles eine Frage des richtigen Package ist, dann wird es spaßig das richtige zu finden.

Grüße

Achim
Member: Achim462
Achim462 Feb 27, 2020 updated at 02:33:16 (UTC)
Goto Top
Ich habe noch eine technische Frage bezüglich Ipsec.

Muss auf der Serverseite wegen VTI auch etwas gemacht werden, um VTI Interface auf der Client Seite zu nutzen?
Oder können fehlende Kommandos auf der Server Seite verursachen, dass die TX Pakete nicht übertragen werden?

Grüße

Achim
Member: aqui
aqui Feb 27, 2020 at 14:07:02 (UTC)
Goto Top
Ja, eine VTI Option sollte beidseitig vorhanden sein ! Ansonsten ist es sehr wahrscheinlich das der Tunnel nicht aufgebaut wird.
Member: Achim462
Achim462 Feb 27, 2020 at 14:20:40 (UTC)
Goto Top
Zitat von @aqui:

Ja, eine VTI Option sollte beidseitig vorhanden sein !

Ahh, da steckt höchst wahrscheinlich der Wurm. Die VPN Techniker werden es vielleicht wissen, aber um was für eine VTI Option handelt es sich?

Grüße

Achim
Member: Achim462
Achim462 Mar 20, 2021 updated at 17:58:30 (UTC)
Goto Top
Ich bin nach wie vor für eine Lösung interessiert, falls es auch ohne vti möglich ist. Bezahlung ist kein Problem.
Falls jemand eine Lösung hat, wie man ein Interface mit KillSwitch für Perfect Privacy konfigurieren kann, dann meldet euch bitte über Private Nachricht.