OPNsense Forum
International Forums => German - Deutsch => Topic started by: mophi on July 31, 2019, 11:24:42 am
-
Hallo Leute,
ich habe 2 OPNsense Hosts über OpenVPN mit einander verbunden. Am 1sten (DMZ) habe ich einen OpenVPN-Server und NGINX reverse Proxy, am 2ten (OpenVPN-Client) mehrere physikalische Subnetze.
Für die Erreichbarkeit der Subnetze habe ich am ersten Host die OpenVPN - Client IP Adresse (172.16.128.2) als Gateway eingetragen und darauf die Subnetze (192.168. ... ) als Routen angelegt.
Vor dem Upgrade hat diese Konfig wunderbar funktioniert, wenn ich jetzt aber versuche am ersten Host einen PING auf ein Subnetz-Interface vom 2ten abzusetzen, bekomme ich folgendes:
PING 192.168.2.1 (192.168.2.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.079 ms
... der erste Host antwortet selbst auf den ECHO Request!???
Hier noch die Routing-Table vom ersten Host:
ipv4 127.0.0.1 link#2 UH 58014 16384 lo0
ipv4 172.16.128.0/24 link#7 U 1459050 1500 ovpns4 LAN
ipv4 172.16.128.1 link#7 UHS 69 16384 lo0
ipv4 192.168.2.0/24 172.16.128.2 UGS 3 1500 ovpns4 LAN
ipv4 192.168.3.0/24 172.16.128.2 UGS 0 1500 ovpns4 LAN
ipv4 192.168.4.0/24 172.16.128.2 UGS 9 1500 ovpns4 LAN
Wenn ihr eine Idee habt, woran das liegen könnte, wäre ich sehr Dankbar!
LG,
Mophi
-
Ich habe jetzt noch Versucht die Situation schematisch darzustellen. ... Vielleicht kann mir ja jemand mit einer Idee weiterhelfen!?
WAN / Internet
:
:
:
.-----:-------.
| OPN:sense |
| (Br:dge) |
'-----:-------'
| 172.16.128.1/24
|
|
LAN | OpenVPN
|
|
| 172.16.128.2/24
.-----:-------.
| OPN:sense | 192.168.4.0/24
| (Br:dge) +------------------------+> Default-GW / 192.168.4.1 ---> Internet
'+----+-------'
| |
| |
| | 192.168.3.0/24
|
| 192.168.2.0/24
-
Irgendwelche Spielereien bei NAT aktiv?
-
Hallo,
nur begrenzt!
Es gibt 3 Portweiterleitungen von der externen IP auf interne Services, siehe Screenshot im Anhang.
Und 2 ausgehende Regeln, sofern die FW als Gateway ins Internet bzw ins "ULK" Netz verwendet wird (trifft in dieser Situation nicht zu!).
Virtuelle IP-Adressen sind keine definiert!
LG
-
PING 192.168.2.1 (192.168.2.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.079 ms
... der erste Host antwortet selbst auf den ECHO Request!???
Hier noch die Routing-Table vom ersten Host:
ipv4 127.0.0.1 link#2 UH 58014 16384 lo0
ipv4 172.16.128.0/24 link#7 U 1459050 1500 ovpns4 LAN
ipv4 172.16.128.1 link#7 UHS 69 16384 lo0
ipv4 192.168.2.0/24 172.16.128.2 UGS 3 1500 ovpns4 LAN
ipv4 192.168.3.0/24 172.16.128.2 UGS 0 1500 ovpns4 LAN
ipv4 192.168.4.0/24 172.16.128.2 UGS 9 1500 ovpns4 LAN
Kannst du die 172.16.128.2 pingen?
-
Ja, das läuft problemlos!
... nur wenn ich versuche eine der anderen Interfaces zu pingen, ... geht es nicht über den OpenVPN Link, sondern wird lokal beantwortet.
Auf dem Quell aber auch auf dem Ziel-Host ist ICMP auch generell gestattet!
Dank dir für deine Hilfe!
-
Hier auch noch die Routing-Table vom Ziel-Host:
... der ICMP-Reply an 172.16.128.1 müsste über das gleiche Interface zurück gehen, wo der Request hergekommen ist!
-
Interessanterweise klappt das ganze, wenn ich den PING in verkehrter Richtung aussende.
Wenn ich am Ziel-Host, mit einem der Interfaces die sonst nicht erreichbar sind, einen Ping an den Quell-Host sende, schafft er es den Reply zurück zu senden.
-
Hat vielleicht noch jemand eine Idee, woran das liegen könnte?
-
Für remote ist das zu komplex, irgendwas kleines ist es. Ich würde immer pingen, Kontrolle wo der Traffic hin geht und wie, also tcpdump an ovpnsX oder ovpncX, bzw, vom LAN, schauen welche Quell und Zieladdressen verwendet werden, während des Pings schauben ob was geblockt oder genattet ist etc.
-
Ich hatte jetzt mit IPSec zweil mal schon dass interfaces die assigned waren auch mit NAT versehen wurden was mit 19.1 nicht war .. kann eigentlich nur sowas sein.
-
Ok, also ich hab mir das über die "Paketaufzeichnung"s-Funktion mal angesehen.
Wenn ich am Quell-Host (172.16.128.1) einen Ping, Porttest oder sonst was über das Gateway (172.16.128.2) an das GW-Interface (192.168.2.1) sende, wird NICHTS aufgezeichnet ... da geht scheinbar nichts über das OpenVPN-Interface hinaus! und der Ping wird durch 127.0.0.1 beantwortet?
Wenn ich aber einen Ping vom GW-Interface (192.168.2.1) an 172.16.128.1 sende, kommt das Paket am richtigen Host an und der Reply kommt auch zurück!
NAT wurde für die betroffenen Schnittstellen keines definiert, siehe Screenshots im Anhang!
Welcher Mechanismus / welches Setting könnte bewirken, dass ein Host den ausgehenden PING selbst mit 127.0.0.1 beantwortet, wenn er selbst kein Interface oder VIP mit der Ziel-IP hat, obwohl er aber eine Route zu dem Ziel in seiner Table hat und die FW nichts blockiert?
Ich habe es auch mit einer VIP mit der Ziel-IP am Quell-Host versucht, um den gegen Check zu machen. Hier wird der PING klarerweise lokal beantwortet, jedoch steht dann die Ziel-IP im Reply und nicht die Loopback-IP.
Hier auch nochmal beide Routing-Tables:
von 172.16.128.1:
ipv4 172.16.128.0/24 link#7 U 968441 1500 ovpns4 LAN
ipv4 172.16.128.1 link#7 UHS 81 16384 lo0
ipv4 172.16.128.2 00:bd:a0:1c:ff:04 UHS 8311 1500 ovpns4 LAN
ipv4 192.168.2.0/24 172.16.128.2 UGS 9 1500 ovpns4 LAN
ipv4 192.168.3.0/24 172.16.128.2 UGS 0 1500 ovpns4 LAN
ipv4 192.168.4.0/24 172.16.128.2 UGS 6 1500 ovpns4 LAN
von 172.16.128.2 / 192.168.2.1:
ipv4 default 192.168.4.1 UGS 983880 1500 igb2 WAN
ipv4 127.0.0.1 link#4 UH 2166 16384 lo0
ipv4 172.16.128.0/24 link#8 U 973370 1500 ovpnc1 ULK
ipv4 172.16.128.2 link#8 UHS 0 16384 lo0
ipv4 192.168.1.0/24 172.16.128.1 UGS 0 1500 ovpnc1 ULK
ipv4 192.168.2.0/24 link#2 U 0 1500 igb1 Core
ipv4 192.168.2.1 link#2 UHS 0 16384 lo0
ipv4 192.168.3.0/24 link#1 U 3259080 1500 igb0 LAN
ipv4 192.168.3.1 link#1 UHS 0 16384 lo0
ipv4 192.168.4.0/24 link#3 U 985453 1500 igb2 WAN
ipv4 192.168.4.100 link#3 UHS 0 16384 lo0
Ich bin ehrlich planlos, was dieses Verhalten noch auslösen könnte!
Vielen Dank, für alle Ideen die eingebracht werden.
LG
-
... also hat niemand eine Idee?