killtec
Goto Top

Open VPN Problem

Hallo,
ich habe ein Problem mit openVPN, bzw. mit einem Tunnel.

Auf der einen Seite steht eine endian Firwall, auf der anderen eine endian Community Firewall.

Von der Community FW wird ein openVPN zur endian aufgebaut. Der Traffic in der Richtung funktioniert ohne Probleme, in der anderen Richtung klappt der Traffic nicht.

Pinge ich von der endian zu einem Host hinter der community FW, klappt das. Jedoch nicht von einem Host hinter der Endian.

Bsp.:
Endian Community LAN-IP 172.17.1.2 (VPN Client)
Endian Fireall LAN-IP 10.0.1.1 (LAN-IP)

per SSH auf die Endian Firewall -> Ping auf Client 172.17.0.10 -> klappt
ping von Client hinter endian FW -> keine Antwort. Traceroute geht korrekt zur FW.

ping von 172.17.0.10 auf 10.0.1.1 -> klappt.

Dieses Problem tritt auf 2 von 3 OpenVPN Tunneln auf.

Also zusammen gefasst: Die FW mit VPN-Server kann alles erreichen, Cleints hinter der FW nicht. Cleints hinter der Client-FW können alles erreichen und bekommen auch ANtworten.

Gruß

Content-Key: 390779

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

Printed on: April 23, 2024 at 11:04 o'clock

Member: aqui
Solution aqui Oct 26, 2018 at 11:56:49 (UTC)
Goto Top
Jedoch nicht von einem Host hinter der Endian.
Kannst du denn wenigstens das IP Interface der Endian hier pingen ?? (ICMP erlaubt in den Regeln der FW !)
Wie immer checken:
  • Routing Tabelle der FWs. Sind beide Netze dort bekannt ? Zeigt auch das die OVPN Konfig korrekt ist (oder nicht)
  • Regelcheck sofern die Endian wie die pfSense ein separates Tunnel Interface hat mit Regeln
  • Ping ist ICMP ! Ist das erlaubt ?
  • Bei den Clients wie immer ist der übliche Verdächtige die lokale Firewall wenns Winblows ist. Die blockt alles was von Fremdnetzen kommt im Default. Ggf. anpassen oder besser immer Drucker usw. pingen die keine lokale FW haben und deren Gateway auf die FW IP zeigt.
Member: killtec
killtec Oct 26, 2018 at 12:09:10 (UTC)
Goto Top
Zitat von @aqui:

Jedoch nicht von einem Host hinter der Endian.
Kannst du denn wenigstens das IP Interface der Endian hier pingen ?? (ICMP erlaubt in den Regeln der FW !)
FW auf FW geht, Client auf FW nicht.

Wie immer checken:
  • Routing Tabelle der FWs. Sind beide Netze dort bekannt ? Zeigt auch das die OVPN Konfig korrekt ist (oder nicht)
Hier wird lediglich Benutzer und Zertifikat hinterlegt + IP-Adresse. Der Routing-Eintrag ist korrekt in der FW gesetzt.

* Regelcheck sofern die Endian wie die pfSense ein separates Tunnel Interface hat mit Regeln
Keine Regeln hier für den Tunnel gesehen.

* Ping ist ICMP ! Ist das erlaubt ?
Ja

* Bei den Clients wie immer ist der übliche Verdächtige die lokale Firewall wenns Winblows ist. Die blockt alles was von Fremdnetzen kommt im Default. Ggf. anpassen oder besser immer Drucker usw. pingen die keine lokale FW haben und deren Gateway auf die FW IP zeigt.
FW ist testhalber aus auf beiden Seiten, leider ist hier nicht die Windows FW aktiv.
Member: aqui
aqui Oct 26, 2018 at 14:54:48 (UTC)
Goto Top
FW auf FW geht
Aber auch die jeweiligen lokalen LAN Interfaces der Firewalls ??
Wenn das geht aber die Endgeräte dahinter nicht, dann hat das so gut wie immer 3 mögliche Ursachen:
  • Gateway oder Route vom Endgerät auf das Firewall Interface fehlt
  • Firewall Regeln am Tunnel Interface blocken den Traffic
  • Lokale Firewall an den Endgeräten blockt den Traffic
Keine Regeln hier für den Tunnel gesehen.
Will heissen...
  • Es gibt kein Tunnel Interface und damit auch keine Regeln
  • Es gibt ein Tunnel Interface aber die Regeln fehlen
Wenn es letzteres ist dann gilt immer Firewall üblich deny any any weisst du aber auch selber.
Was sagt den die Routing Tabelle der FW ?
Member: killtec
killtec Oct 29, 2018, updated at Feb 10, 2020 at 14:31:14 (UTC)
Goto Top
Hi,

VPN Firewall ist aus
Outgoing FW ist aus

Hier mal aus dem Netz 10.0.0.0/16 zu 172.17.0.0/16
von der Firewall auf Client hinter der Firewall:
root@Defender:~ # traceroute 172.17.0.10
traceroute to 172.17.0.10 (172.17.0.10), 30 hops max, 46 byte packets
 1  vpn.mynetwork1.local (10.0.6.1)  5.451 ms  5.322 ms  4.710 ms
 2  172.17.0.10 (172.17.0.10)  5.722 ms  *  5.648 ms
root@Defender:~ #

vom Client aus 10.0.0.0/16 geht der Traceroute in einen Timeout.

Config des VPN-Clients (egal ob NAT aktiv oder nicht, kommt immer das gleiche raus, Routen sind korrekt):

nat1
nat21


Datenweg von 172.17.0.0/16 zu 10.0.0.0/16
Cleint Tracert:
C:\Users\user>tracert 10.0.0.6

Routenverfolgung zu 10.0.0.6 über maximal 30 Hops

  1    <1 ms    <1 ms    <1 ms  efw-main.mynet.lan [172.17.1.2]
  2    10 ms     5 ms     5 ms  10.0.0.6

Ablaufverfolgung beendet.

ICMP Firewall
root@efw-main:~ # ping 10.0.06
PING 10.0.06 (10.0.0.6) 56(84) bytes of data.
64 bytes from 10.0.0.6: icmp_seq=1 ttl=128 time=5.04 ms
64 bytes from 10.0.0.6: icmp_seq=2 ttl=128 time=5.33 ms
64 bytes from 10.0.0.6: icmp_seq=3 ttl=128 time=5.35 ms
64 bytes from 10.0.0.6: icmp_seq=4 ttl=128 time=4.85 ms

Gruß
Member: aqui
aqui Oct 30, 2018 at 09:34:55 (UTC)
Goto Top
Routing Tabelle ? netstat -r -n
Member: killtec
killtec Oct 30, 2018 at 13:57:04 (UTC)
Goto Top
Hi Aqui,
habs gefunden. Es war ein Routing-Problem. Von zwei Cleints aus (von denen ich getestet hatte) ging das Routing auf default über einen bestimmten Uplink. Das hatte zur Folge, dass hier die Pakete nicht korrekt geroutet wurden.
Habe das eben mal aus gemacht und schon klappt es.

Danke. face-smile
Member: aqui
aqui Oct 30, 2018 at 19:21:31 (UTC)
Goto Top
Klasse ! Wie immer: Kleine Ursache.... aber sieht man im ersten Moment nicht face-wink
Dann können wir ja entspannt in den Feiertag !
Member: killtec
killtec Nov 01, 2018 at 11:45:13 (UTC)
Goto Top
Das stimmt. face-smile