30.07.2024

1511

Pakete gehen beim Routing von IPSec nach Wireguard verloren (Route-Based-VPNs)

Hallöchen, ich schon wieder,

kaum hat man das eine Problem gelöst, schon geht das nächste los...
Mein Setup ist folgendes:
Fortigate ===Route-Based-IPSec-Tunnel=== Debian-Server (strongswan, frr) ===Route-Based-Wireguard=== Site2 (Opnsense)

Sowohl der IPSec (local_ts und remote_ts = 0.0.0.0/0) als auch wireguard (allowedIPs = 0.0.0.0/0) sind route based und haben von mir eine /30er Interface-IP bekommen. Über FRR werden BGP-Routen ausgetauscht und sind auch überall korrekt bekannt.

Ein Ping geht vom Debian Server aus in alle Richtungen mit Antwort. Vom Wireguard-Netz aus kommt man auch ins IPSec-Netz und dort ins LAN (tcpdump als auch die Forti-Logs beweisen das). Antworten aus dem IPSec-Netz in Richtung Debian-Server, die dann weiter ins Wireguard sollen bleiben aber scheinbar auf dem Debian Server irgendwo hängen. Ein tcpdump zeigte auch hier, dass die Pakete über den IPSec-Tunnel reinkommen aber auf keinem anderen Interface tauchen sie auf. nftables hab ich schon ausgeschlossen als Fehlerquelle (Policy accept in INPUT und FORWARD chains). MTU kam mir dann noch aber dann würden ja die Pakete überhaupt nicht fließen oder irre ich mich da? Die MTU ist zwar verschieden (WG 1412, IPSec 1480) aber nachdem vom Wireguard in Richtung IPSec was geht sollte das ja nicht das Problem sein (im Zweifel wird halt fragmentiert). Aber auch mit gleicher MTU (hab mal 1200 probiert) besteht das Problem. Es besteht auch bei Verbindungen zu anderen Wireguard-Netzen auf dem Debian-Server. Terminiert das Paket aber auf dem Debian-Server selbst (auch auf einem seiner anderen Wireguard-IPs), kommt eine Verbindung zustande.

Hab ich evtl. irgendwas in der sysctl vergessen (IP-Forwarding ist eingeschalten, sonst würden ja auch die WG Pakete nicht im IPSec Tunnel landen).

Danke schonmal für eure Antworten!
Grüße
Ketanest

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

Content-ID: 11414856666

Url: https://administrator.de/forum/pakete-gehen-beim-routing-von-ipsec-nach-wireguard-verloren-route-based-vpns-11414856666.html

Ausgedruckt am: 30.12.2024 um 17:12 Uhr

27 Kommentare

Neuester Kommentar

Hast du in der OPNsense das automatische Lernen der Wireguard Routen abgeschaltet, sprich den Haken gesetzt bei "Disable Routes"??

Bei der Aktivierung von dynamischem Routing mit OSPF oder BGP ist das Abschalten des Cryptokey Routings essentiell wichtig.

Was sagt die BGP Routing Tabelle und auch die globale Routing Tabelle auf dem Debian Server? "Sieht" der Server alle remoten IP Netze und das zu jeder Zeit?

2 unterschiedliche MTU Größen auf den Tunneln zu fahren ist natürlich kontraproduktiv und wenig intelligent. Wireguard nutzt im Default 1420. Warum man das dann überflüssigerweise noch auf 1412 anpasst ist dann mehr oder minder sinnfrei. Deutlich sinnvoller wäre es die Tunnel MTU homogen zu gestalten also auch z.B. IPsec auf 1420 anzupassen um eine Fragemntierung zwischen den Tunneln sicher zu vermeiden.

Hast du in der OPNsense das automatische Lernen der Wireguard Routen abgeschaltet, sprich den Haken gesetzt bei "Disable Routes"??

Jap, is defintiv aus.

Was sagt die BGP Routing Tabelle und auch die globale Routing Tabelle auf dem Debian Server? "Sieht" der Server alle remoten IP Netze und das zu jeder Zeit?

Jap, die relevanten Einträge hier:

Global:

2.0.4/30 dev ltb-fw01 proto kernel scope link src 10.2.0.5
2.0.48/30 dev tfd-lwl proto kernel scope link src 10.2.0.49
168.10.0/24 nhid 45 via 10.2.0.50 dev tfd-lwl proto bgp metric 20
168.12.0/24 nhid 45 via 10.2.0.50 dev tfd-lwl proto bgp metric 20
168.13.0/24 nhid 45 via 10.2.0.50 dev tfd-lwl proto bgp metric 20
168.14.0/24 nhid 45 via 10.2.0.50 dev tfd-lwl proto bgp metric 20
168.112.0/24 nhid 45 via 10.2.0.50 dev tfd-lwl proto bgp metric 20
168.174.0/24 nhid 45 via 10.2.0.50 dev tfd-lwl proto bgp metric 20
168.177.0/24 nhid 43 via 10.2.0.6 dev ltb-fw01 proto bgp metric 20
168.178.0/24 nhid 43 via 10.2.0.6 dev ltb-fw01 proto bgp metric 20

BGP:

BGP table version is 73, local router ID is x.x.x.x, vrf id 0
Default local pref 100, local AS 65001
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self  
Origin codes:  i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.2.0.4/30      0.0.0.0                  0         32768 i
*> 10.2.0.48/30     0.0.0.0                  0         32768 i
*> 192.168.10.0/24  10.2.0.50               10             0 65009 i
*> 192.168.12.0/24  10.2.0.50               10             0 65009 i
*> 192.168.13.0/24  10.2.0.50               10             0 65009 i
*> 192.168.14.0/24  10.2.0.50               10             0 65009 i
*> 192.168.112.0/24 10.2.0.50               10             0 65009 i
*> 192.168.174.0/24 10.2.0.50               10             0 65009 i
*> 192.168.177.0/24 10.2.0.6                 0             0 65005 i
*> 192.168.178.0/24 10.2.0.6                 0             0 65005 i

Displayed  17 routes and 18 total paths

2 unterschiedliche MTU Größen auf den Tunneln zu fahren ist natürlich kontraproduktiv und wenig intelligent. Wireguard nutzt im Default 1420. Warum man das dann überflüssigerweise noch auf 1412 anpasst ist dann mehr oder minder sinnfrei. Deutlich sinnvoller wäre es die Tunnel MTU homogen zu gestalten also auch z.B. IPsec auf 1420 anzupassen um eine Fragemntierung zwischen den Tunneln sicher zu vermeiden.

Default MTU 1500 abzüglich PPPoE abzüglich IPv6 abzüglich Wireguard gibt 1412, deshalb 1412, weil auf der einen seite ne PPPoE Einwahl erfolgt. Aber nichts desto trotz gings ja auch mit meinem Experiment mit ner MTU von 1200 nicht.

Was mich halt so stutzig macht ist, dass die Pakete in die eine Richtung (WG -> Debian -> IPSec) fließen aber in die andere (IPSec -> Debian -> WG) nicht bzw. eben aufm Debian Server hängen bleiben.

Die nftables FOTWARD chain sieht aktuell testweise so aus (daran sollte also also auch definitiv nicht liegen):

chain FORWARD {
        type filter hook forward priority filter
        policy accept
        #accept forward any on vpn
        iifname {"andere WG interfaces","tfd-lwl","tfd-lte"} accept  
        #accept related, established
        ct state related,established accept
        #reject anything else
        #reject
        accept
    }

Moin,

wie sehen denn die Regeln auf der OPNsense aus?
Scheinbar lässt du den Traffic nicht zu.

Gruß
Spirit

Zitat von @Spirit-of-Eli:

Moin,

wie sehen denn die Regeln auf der OPNsense aus?
Scheinbar lässt du den Traffic nicht zu.

Gruß
Spirit

Da hab ich testweise auch ne any Regel gebaut. Es scheitert ja schon daran, dass der Traffic Richtung Wireguard (OPNSense) das entsprechende Interface aufm Debian Server schon nicht verläst (zeigt ein tcpdump).

Hier rennt das fehlerlos auf einem Debian 12. Allerdings mit einem klassischen Setup.
Der Debian Server bedient unter Strongswan ne Handvoll Fritzboxen mit IKEv1 agressive und ist ein IKEv2 Dialin VPN Server für alle onboard Clients der bekannten OS und Smartphones.
Parallel dazu einige neue WG Fritzboxen und einige Android Clients mit WG.
Da kann erwartungsgemäß jeder mit jedem ohne irgendwelche relevanten Ausfälle.

Zitat von @aqui:

Hier rennt das fehlerlos auf einem Debian 12. Allerdings mit einem klassischen Setup.
Der Debian Server bedient unter Strongswan ne Handvoll Fritzboxen mit IKEv1 agressive und ist ein IKEv2 Dialin VPN Server für alle onboard Clients der bekannten OS und Smartphones.
Parallel dazu einige neue WG Fritzboxen und einige Android Clients mit WG.
Da kann erwartungsgemäß jeder mit jedem ohne irgendwelche relevanten Ausfälle.

Seltsam... Ich hab auch n Debian 12. Der IPSec isn IKEv2.
Kannst du mir evtl. deine sysctl für die betreffenden Interfaces zukommen lassen? Ich vermute, da könnte noch der Wurm drin sein.

Hab da lediglich das "#" vor dem net.ipv4.ip_forward=1 entfernt ansonsten ist die Default und nichts weiter verändert.
IPsec hat 2 Konf Dateien unter /etc/swanctl/conf.d/ jeweils fürs Client VPN und die FBs und WG entsprechende Konf wg0.conf Datei. Klassischer Standard...

Komisch... Bei mir ist halt wegen Route-Based noch disable_policy=0 aber sonst auch genau wie bei dir.

Ich hab jetzt mal testweise damit ich wieder arbeiten kann nen IPSec-Tunnel (Route-Based) zwischen Forti und OPN gebaut, der rennt einwandfrei. Der Debian Server ist von der Forti aus über die OPN auch wieder erreichbar.

Kann sein das je nachdem über welche Tools du den Wireguard Tunnel aufbaust die Firewall-Tags des VTI Tunnels hier zu einem Routing-Fehler führen.
Checke die Routing Rules ip rule show und die Tabellen ip route show table all
Nimm dann mal testweise statt einem VTI Tunnel einen simplen GRE Tunnel zwischen Forti und Debian über den IPSec Tunnel.
https://docs.fortinet.com/document/fortigate/6.4.2/sd-wan-deployment-wit ...

Hier klappt das im Test problemlos sowohl via VTI als auch GRE zu einem Strongswan mittels IKEv2 VPN und von dort aus über einen Wireguard-Tunnel zu routen.
Immer schön drauf achten das alle Stellen auch wieder korrekte Routen zur Absenderadresse besitzen, das vergisst man schnell mal was.

Gruß Strods

das alle Stellen auch wieder korrekte Routen zur Absenderadresse besitzen

Wenn er beim BGP nicht geschlampert hat sollte das ja eigentlich der Fall sein. 😉

Zitat von @aqui:

das alle Stellen auch wieder korrekte Routen zur Absenderadresse besitzen

Wenn er beim BGP nicht geschlampert hat sollte das ja eigentlich der Fall sein. 😉

Jepp, aber wie immer gilt Vertrauen ist gut Kontrolle ist besser.

...wie Herr Lenin schon sagte! 👍

Zitat von @13910172396:

Kann sein das je nachdem über welche Tools du den Wireguard Tunnel aufbaust die Firewall-Tags des VTI Tunnels hier zu einem Routing-Fehler führen.
Checke die Routing Rules ip rule show und die Tabellen ip route show table all
Nimm dann mal testweise statt einem VTI Tunnel einen simplen GRE Tunnel zwischen Forti und Debian über den IPSec Tunnel.
https://docs.fortinet.com/document/fortigate/6.4.2/sd-wan-deployment-wit ...

Hier klappt das im Test problemlos sowohl via VTI als auch GRE zu einem Strongswan mittels IKEv2 VPN und von dort aus über einen Wireguard-Tunnel zu routen.
Immer schön drauf achten das alle Stellen auch wieder korrekte Routen zur Absenderadresse besitzen, das vergisst man schnell mal was.

Gruß Strods

Das werd ich heute abend mal testen. Der Tunnel wird mit wg-quick aufgebaut, die nötige config steht jeweils in der /etc/wireguard/(TUNNEL).conf

Zitat von @aqui:

das alle Stellen auch wieder korrekte Routen zur Absenderadresse besitzen

Wenn er beim BGP nicht geschlampert hat sollte das ja eigentlich der Fall sein. 😉

Zitat von @13910172396:

Zitat von @aqui:

das alle Stellen auch wieder korrekte Routen zur Absenderadresse besitzen

Wenn er beim BGP nicht geschlampert hat sollte das ja eigentlich der Fall sein. 😉

Jepp, aber wie immer gilt Vertrauen ist gut Kontrolle ist besser.

Mehrfach geprüft

Routing-technisch passt alles.

Danke euch schonmal! Mal sehen obs was bringt.

Mal sehen obs was bringt.

Erst mal mit einem kühlen Blonden in den Garten setzen, dann löst sich das Brett vorm Kopp meist wie von selbst

. Good Luck 👍. Eine Runde für alle 🍺

Zitat von @13910172396:

Mal sehen obs was bringt.

Erst mal mit einem kühlen Blonden in den Garten setzen, dann löst sich das Brett vorm Kopp meist wie von selbst

. Good Luck 👍. Eine Runde für alle 🍺

Also viel gebracht hat das kühle Blonde leider nicht. Das mit dem GRE Tunnel hab ich nicht verstanden, wie das gehen soll. Ich baue den IPSec Tunnel nicht um und lege statt dem vti einen GRE Tunnel an? Also:

ip tunnel add NAME local x.x.x.x remote y.y.y.y mode gre key 42

Und auf den Konfigurier ich dann die IPs analog zum vti?

Zitat von @ketanest112:
Das mit dem GRE Tunnel hab ich nicht verstanden, wie das gehen soll. Ich baue den IPSec Tunnel nicht um und lege statt dem vti einen GRE Tunnel an? Also:

ip tunnel add NAME local x.x.x.x remote y.y.y.y mode gre key 42

Und auf den Konfigurier ich dann die IPs analog zum vti?

Nein. IPSec Tunnel auf der Fort mit einer Phase2 Policy SRC = [WAN-IP-Forti]/32 DST = [WAN-IP-DEBIAN]/32

Dann an der Forti einen neuen GRE-Tunnel anlegen mit LOCAL = [WAN-IP-Forti] und REMOTE = [WAN-IP-DEBIAN]

Dem GRE Tunnel Interface auf der Forti eine Transfernetz IP geben z.B. 10.7.7.1/30

Auf dem Debian ein neues GRE Interface anlegen

ip tunnel add name gre-forti type gre local [WAN-IP-DEBIAN] remote [WAN-IP-Forti] 
ip address add dev gre-forti 10.7.7.2/30
ip link set gre-forti up

Dann lässt sich wie gewohnt über das GRE Transfernetz routen.

Also mit GRE Tunnel geht überhaupt nix. Egal ob v4 oder v6. Musste v6 auch mal testen weil v4 hinter CGNAT liegt (Forti Seite).

Ich bin grad immer noch am überlegen, was der Debian Server anders macht als die OPNsense beim Routing. Weil über die gehts ja, die IPSec Tunnel und Interface Config auf der Forti ist (bis auf die Adressen) exakt dieselbe.

Zitat von @ketanest112:

Also mit GRE Tunnel geht überhaupt nix. Egal ob v4 oder v6. Musste v6 auch mal testen weil v4 hinter CGNAT liegt (Forti Seite).

Klappt hier wie erwartet aber ebenso einwandfrei, ergo machst du immer noch einen Fehler den wir nicht sehen können. Und bei IPv6 musst du natürlich logischerweise einen ip6gre Tunnel nehmen keinen gre.

Klappt hier wie erwartet aber ebenso einwandfrei, ergo machst du immer noch einen Fehler den wir nicht sehen können.

Kann sein das je nachdem über welche Tools du den Wireguard Tunnel aufbaust die Firewall-Tags des VTI Tunnels hier zu einem Routing-Fehler führen.

Genau das vermute ich eben auch, aber welche Tags könnten das sein?

Checke die Routing Rules ip rule show und die Tabellen ip route show table all

ip rule show
     from all lookup local
   from all lookup 220
 from all lookup main
 from all lookup default

ip route show table all

sieht für mich persönlich auch gut aus, die Routen die ich in die entsprechenden Zielnetze brauche sind da. Nachdem auf dem Debian ein Routing von WG zu WG als auch vom Server selbst zu allen benötigten Netzen möglich ist aber aus dem IPSec VTI eben nicht, muss der Fehler ja hier liegen. Kann ich euch noch irgendwas anbieten (config, log) was aufschlussreich wäre?

Also ich das Ganze grad nochmal auf nem anderen Debian Server nachgestellt, gleiches Problem. Muss also wohl echt an der Config liegen.

Der Tunnel wird mit wg-quick aufgebaut

Geht auch mit systemctl restart wg-quick@wg0.service

Das mit dem GRE Tunnel hab ich nicht verstanden

Grob anhand Praxis Beispielen wird das u.a. HIER erklärt.

Geht auch mit systemctl restart wg-quick@wg0.service

Genau das meinte ich ja. So überleben die Tunnel dann auch nen Reboot.

eine der WG-Configs sieht so aus (die anderen analog):

[Interface]
Address = 10.2.0.13/30
PrivateKey = KEY
ListenPort = 30004
MTU = 1412
Table = off

[Peer]
PublicKey = KEY
AllowedIPs = 0.0.0.0/0
Endpoint = DNS:30004

Mit der jeweils anderen IP im Transfernetz wird dann ne BGP Session aufgebaut und Routen ausgetauscht.
Also eig keine besondere config.

So überleben die Tunnel dann auch nen Reboot.

Jein! Nur dann wenn du auch ein systemctl enable wg-quick@wg0.service ausgeführt hast!

Genau das meinte ich ja.

Hast du aber dann zumindest leider missverständlich und doppeldeutig ausgedrückt.

Kann auch bedeuten das du wg-quick down wg0 bzw. das Pendant wg-quick up wg0 übers CLI benutzt. Aber egal... Zurück zum Thema!

Reservierte IANA Ports zu verwenden ist auch nicht gerade die feine englische Art.

Wenn dann solltest du als verantwortungsvoller Admin bei den WG Ports immer im Bereich der freien Ephemeral Ports bleiben!

Wuhuuu, Problem gelöst. Es war eine sysctl Einstellung:
Auf dem Wireguard Interface muss man xfrm deaktivieren:

sysctl net.ipv4.conf.[INTERFACE].disable_xfrm=1

Jein! Nur dann wenn du auch ein systemctl enable wg-quick@wg0.service ausgeführt hast! face-wink

Auch das meinte ich

Hast du aber dann zumindest leider missverständlich und doppeldeutig ausgedrückt. face-sad

Tut mir leid, beim zweiten Mal schon wieder... -.-

Kann auch bedeuten das du wg-quick down wg0 bzw. das Pendant wg-quick up wg0 übers CLI benutzt. Aber egal... Zurück zum Thema!

Ne wie gesagt, habs über systemctl enable aktiviert.

Danke trotzdem vielmals für eure Hilfe (auch in den anderen Threads)!!! Ich hoffe, jetzt nerv ich nicht mehr rum haha