26.10.2018

3564

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ß

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

Content-ID: 390779

Url: https://administrator.de/forum/open-vpn-problem-390779.html

Ausgedruckt am: 02.04.2025 um 08:04 Uhr

8 Kommentare

Neuester Kommentar

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.

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 ?

* 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.

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 ?

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

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ß

Routing Tabelle ? netstat -r -n

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.