Hallo zusammen,
nachdem ich mittlerweile meine Firewall bei der Fehlersuche ziemlich zerschossen habe brauche ich mal etwas Hilfe um wieder auf die ,,Spur" zu kommen. Um das ganze nicht soweit ausufern zu lassen versuche ich Step by Step meine Probleme zu beschreiben.
Das erste Problem geht um das Thema Routing. Hier meine aktuelles Problem:
Externer Router [192.168.8.1/24] ist via OpenVPN [10.1.1.0/24] mit der opnsense verbunden.
Aus diesem externen Netz kann ich problemlos auf die ,,Hardware" Interfaces [192.168.x.y/16] der opnsense zugreifen.
Ein Traceroute ergibt:
Quotetraceroute to 192.168.30.1 (192.168.30.1), 30 hops max, 60 byte packets
1 192.168.8.1 (192.168.8.1) 0.671 ms 0.642 ms 0.716 ms
2 10.1.1.1 (10.1.1.1) 27.318 ms 27.508 ms 27.842 ms
3 192.168.30.1 (192.168.30.1) 28.091 ms 29.027 ms 29.376 ms
Problem:
Aus diesem externen Netz [192.168.8.1/24] möchte ich ebenfalls auf eine IP [192.168.181.1] zugreifen, welche via IPSEC verbunden ist. Randinfo: Der IPSEC-Tunnel erlaubt nur [192.168.0.0/16] als Source.
Eine Traceroute aus dem externen Netz [192.168.8.1/24] auf diese IP ergibt:
Quotetraceroute to 192.168.181.1 (192.168.181.1), 30 hops max, 60 byte packets
1 192.168.8.1 (192.168.8.1) 0.700 ms 0.615 ms 0.657 ms
2 10.1.1.1 (10.1.1.1) 55.723 ms 64.693 ms 73.057 ms
3 xyz.dip0.t-ipconnect.de (x.x.x.x) 77.596 ms !N 78.446 ms !N 78.643 ms !N
Frage: Warum leitet die opnsense das ganze auf mein WAN Gateway?
Auf der opensense erscheint folgendes:
QuoteOPNVPNTunnel Sep 12 12:04:57 10.1.1.2:43098 192.168.181.1:33441 udp
OPNVPNTunnel Sep 12 12:04:57 10.1.1.2:37089 192.168.181.1:33440 udp
OPNVPNTunnel Sep 12 12:04:57 10.1.1.2:33534 192.168.181.1:33439 udp
OPNVPNTunnel Sep 12 12:04:57 10.1.1.2:51400 192.168.181.1:33438 udp
OPNVPNTunnel Sep 12 12:04:57 10.1.1.2:55097 192.168.181.1:33437 udp
Anbei meine Routes der opnsense:
QuoteDestination Gateway Flags Netif Expire
default 62.155.x.x UGS pppoe0
10.1.1.0/24 10.1.1.2 UGS ovpns1
10.1.1.1 link#12 UHS lo0
10.1.1.2 link#12 UH ovpns1
46.81.94.x link#13 UHS lo0
62.155.x.x link#13 UH pppoe0
127.0.0.1 link#8 UH lo0
192.168.8.0/24 10.1.1.2 UGS ovpns1
192.168.10.0/24 link#2 U igb1
192.168.10.254 link#2 UHS lo0
192.168.20.0/24 link#3 U igb2
192.168.20.254 link#3 UHS lo0
192.168.30.0/24 link#4 U igb3
192.168.30.254 link#4 UHS lo0
192.168.180.0/24 62.155.x.x US pppoe0
192.168.181.0/24 62.155.x.x US pppoe0
192.168.182.0/24 62.155.x.x US pppoe0
217.237.148.x 62.155.x.x UGHS pppoe0
217.237.151.x 62.155.x.x UGHS pppoe0
Frage: Warum gehen keine Pakete in das Zielnetz? Ist die statische route die automatisch gesetzt wird korrekt? Wie und wo kann ich weitersuchen?
Das Ganze hat mal funktioniert bis zum Zeitpunkt x. Hierzu hatte ich zusätzlich noch eine Outbound NAT Rule angelegt, die den Datenverkehr dann via statischem Port und als Translation LAN Adress mappt, damit dieser auch durch den ipsec Tunnel geht. Die Regel greift aber nicht mehr lt. Livelog– siehe log.
Im anderen Forum hatte ich bereits vorgestern mal gepostet, da hielt ich das ganze aber für ein Problem mit Wireguard. Mittlerweile funktioniert aber selbst das hier nicht mehr.
Auch nach nach tagelanger Fehlersuche und dem Einspielen eines Backups ist die alte Situation nicht wieder herzustellen. Dementsprechend muss ich aktuell davon ausgehen, das sich in den letzten zwei Updates, die ich direkt hintereinander gemacht habe, sich etwas geändert hat.
Damit ich über OpenVPN Clients überhaupt wieder auf die IPSecClients zugreifen kann musste ich die 10er IPSEC Tunneladresse ebenfalls in den Bereich 192.168.x.x versesetzen.
Kann mir denn niemand wirklich helfen oder einen Tipp geben?