mikado90
Nov 17, 2015, updated at Dec 01, 2015 (UTC)
view3851
view33
0
Goto Top

OpenVPN hinter Palo Alto Firewall. Mehrere VPN-Server in DMZ

GermansolvedQuestionNetworks
Hi!

Ich habe einen OpenVPN-Server hinter einer Palo Alto PA500 installiert. Diese kann kein IPsec etc zu einzelnen PCs sondern "nur" Tunnel zu anderen Firewall-Geräten (Side by Side).

Ich nutze Port 1194 TCP und bekomme am Client folgende Fehlermeldung:


Tue Nov 17 13:20:31 2015 NOTE: --user option is not implemented on Windows
Tue Nov 17 13:20:31 2015 NOTE: --group option is not implemented on Windows
Tue Nov 17 13:20:31 2015 OpenVPN 2.3.8 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Aug 4 2015
Tue Nov 17 13:20:31 2015 library versions: OpenSSL 1.0.1p 9 Jul 2015, LZO 2.08
Tue Nov 17 13:20:31 2015 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Tue Nov 17 13:20:31 2015 Need hold release from management interface, waiting...
Tue Nov 17 13:20:32 2015 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Tue Nov 17 13:20:32 2015 MANAGEMENT: CMD 'state on'
Tue Nov 17 13:20:32 2015 MANAGEMENT: CMD 'log all on'
Tue Nov 17 13:20:32 2015 MANAGEMENT: CMD 'hold off'
Tue Nov 17 13:20:32 2015 MANAGEMENT: CMD 'hold release'
Tue Nov 17 13:20:32 2015 Socket Buffers: R=[8192->8192] S=[8192->8192]
Tue Nov 17 13:20:32 2015 Attempting to establish TCP connection with [AF_INET]80.xxx.xx.xxx:1194 [nonblock]
Tue Nov 17 13:20:32 2015 MANAGEMENT: >STATE:1447762832,TCP_CONNECT,,,
Tue Nov 17 13:20:33 2015 TCP connection established with [AF_INET]80.xxx.xx.xxx:1194
Tue Nov 17 13:20:33 2015 TCPv4_CLIENT link local: [undef]
Tue Nov 17 13:20:33 2015 TCPv4_CLIENT link remote: [AF_INET]80.xxx.xx.xxx:1194
Tue Nov 17 13:20:33 2015 MANAGEMENT: >STATE:1447762833,WAIT,,,
Tue Nov 17 13:20:44 2015 read TCPv4_CLIENT: Connection timed out (WSAETIMEDOUT) (code=10060)
Tue Nov 17 13:20:44 2015 Connection reset, restarting [-1]
Tue Nov 17 13:20:44 2015 SIGUSR1[soft,connection-reset] received, process restarting
Tue Nov 17 13:20:44 2015 MANAGEMENT: >STATE:1447762844,RECONNECTING,connection-reset,,
Tue Nov 17 13:20:44 2015 Restart pause, 5 second(s)
Tue Nov 17 13:20:49 2015 Socket Buffers: R=[8192->8192] S=[8192->8192]
Tue Nov 17 13:20:49 2015 Attempting to establish TCP connection with [AF_INET]80.xxx.xx.xxx:1194 [nonblock]
Tue Nov 17 13:20:49 2015 MANAGEMENT: >STATE:1447762849,TCP_CONNECT,,,
Tue Nov 17 13:20:50 2015 TCP connection established with [AF_INET]80.xxx.xx.xxx:1194
Tue Nov 17 13:20:50 2015 TCPv4_CLIENT link local: [undef]
Tue Nov 17 13:20:50 2015 TCPv4_CLIENT link remote: [AF_INET]80.xxx.xx.xxx:1194
Tue Nov 17 13:20:50 2015 MANAGEMENT: >STATE:1447762850,WAIT,,,
Tue Nov 17 13:21:00 2015 read TCPv4_CLIENT: Connection timed out (WSAETIMEDOUT) (code=10060)
Tue Nov 17 13:21:00 2015 Connection reset, restarting [-1]
Tue Nov 17 13:21:00 2015 SIGUSR1[soft,connection-reset] received, process restarting
Tue Nov 17 13:21:00 2015 MANAGEMENT: >STATE:1447762860,RECONNECTING,connection-reset,,
Tue Nov 17 13:21:00 2015 Restart pause, 5 second(s)
Tue Nov 17 13:21:05 2015 Socket Buffers: R=[8192->8192] S=[8192->8192]
Tue Nov 17 13:21:05 2015 Attempting to establish TCP connection with [AF_INET]80.xxx.xx.xxx:1194 [nonblock]
Tue Nov 17 13:21:05 2015 MANAGEMENT: >STATE:1447762865,TCP_CONNECT,,,
Tue Nov 17 13:21:06 2015 TCP connection established with [AF_INET]80.xxx.xx.xxx:1194
Tue Nov 17 13:21:06 2015 TCPv4_CLIENT link local: [undef]
Tue Nov 17 13:21:06 2015 TCPv4_CLIENT link remote: [AF_INET]80.xxx.xx.xxx:1194
Tue Nov 17 13:21:06 2015 MANAGEMENT: >STATE:1447762866,WAIT,,,
Tue Nov 17 13:21:16 2015 read TCPv4_CLIENT: Connection timed out (WSAETIMEDOUT) (code=10060)
Tue Nov 17 13:21:16 2015 Connection reset, restarting [-1]
Tue Nov 17 13:21:16 2015 SIGUSR1[soft,connection-reset] received, process restarting
Tue Nov 17 13:21:16 2015 MANAGEMENT: >STATE:1447762876,RECONNECTING,connection-reset,,
Tue Nov 17 13:21:16 2015 Restart pause, 5 second(s)
Tue Nov 17 13:21:21 2015 Socket Buffers: R=[8192->8192] S=[8192->8192]
Tue Nov 17 13:21:21 2015 Attempting to establish TCP connection with [AF_INET]80.xxx.xx.xxx:1194 [nonblock]
Tue Nov 17 13:21:21 2015 MANAGEMENT: >STATE:1447762881,TCP_CONNECT,,,
Tue Nov 17 13:21:22 2015 TCP connection established with [AF_INET]80.xxx.xx.xxx:1194
Tue Nov 17 13:21:22 2015 TCPv4_CLIENT link local: [undef]
Tue Nov 17 13:21:22 2015 TCPv4_CLIENT link remote: [AF_INET]80.xxx.xx.xxx:1194
Tue Nov 17 13:21:22 2015 MANAGEMENT: >STATE:1447762882,WAIT,,,
Tue Nov 17 13:21:32 2015 read TCPv4_CLIENT: Connection timed out (WSAETIMEDOUT) (code=10060)
Tue Nov 17 13:21:32 2015 Connection reset, restarting [-1]
Tue Nov 17 13:21:32 2015 SIGUSR1[soft,connection-reset] received, process restarting
Tue Nov 17 13:21:32 2015 MANAGEMENT: >STATE:1447762892,RECONNECTING,connection-reset,,
Tue Nov 17 13:21:32 2015 Restart pause, 5 second(s)
Tue Nov 17 13:21:37 2015 Socket Buffers: R=[8192->8192] S=[8192->8192]
Tue Nov 17 13:21:37 2015 Attempting to establish TCP connection with [AF_INET]80.xxx.xx.xxx:1194 [nonblock]
Tue Nov 17 13:21:37 2015 MANAGEMENT: >STATE:1447762897,TCP_CONNECT,,,
Tue Nov 17 13:21:38 2015 TCP connection established with [AF_INET]80.xxx.xx.xxx:1194
Tue Nov 17 13:21:38 2015 TCPv4_CLIENT link local: [undef]
Tue Nov 17 13:21:38 2015 TCPv4_CLIENT link remote: [AF_INET]80.xxx.xx.xxx:1194
Tue Nov 17 13:21:38 2015 MANAGEMENT: >STATE:1447762898,WAIT,,,

Am OpenVPN-Server habe ich mich an diese Anleitung gehalten:
https://www.digitalocean.com/community/tutorials/how-to-set-up-an-openvp ...

Den Port 1194 habe ich auch in der ufw freigegeben (TCP und UDP).

Egal ob TCP oder UDP (jeweils in der server.conf + client.conf angepasst) funktioniert nicht.

In der PaloAlto habe ich von trust und untrust alles zugelassen. Dennoch denke ich das die PaloAlto etwas blockt... im "Monitor" kann ich leider nichts auffälliges sehen.

Habt ihr eine Idee? Benötigt ihr Screenshots der Konfig?

Danke schon jetzt für eure Mühe
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 288596

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

Printed on: April 18, 2024 at 13:04 o'clock

33 Comments
Latest comment
Goto Top
Mitglied: 119944
119944 Nov 17, 2015 at 12:37:10 (UTC)
Goto Top
Moin,

Ich nutze Port 1194 TCP und bekomme am Client folgende Fehlermeldung:
Hier sollte man lieber UDP verwenden weil dies schneller ist.
Außerdem verwendet dein verlinktes Tutorial UDP!

Den Port 1194 habe ich auch in der ufw freigegeben (TCP und UDP).
Hast du diesen auch zum OpenVPN Server weitergeleitet?

VG
Val
Member: mikado90
mikado90 Nov 17, 2015 updated at 12:51:29 (UTC)
Goto Top
Weitere Infos:

Der OpenVPN Server steht in der DMZ.

Hier ist befindet sich auch noch die alte (aktuell verwendete) VPN-Appliance.

Diese hat die feste IP-Adresse: 80.xxx.xxx.1

Der neue OpenVPN-Server bekommt die feste IP 80.xxx.xxx.5

Von der PaloAlto wird also alles am Anschluss 7 in das DMZ geroutet: 80.xxx.xxx.1/29

Wir besitzen also:
80.xxx.xxx.0
80.xxx.xxx.1
80.xxx.xxx.2
80.xxx.xxx.3
80.xxx.xxx.4
80.xxx.xxx.5 - frei, also kann für OpenVPN Server verwendet werden
80.xxx.xxx.6

Am OpenVPN Server habe ich eth0 im interneen Netz mit 172.x.x.100 und eth1 (im dmz vlan) mit der 80.xxx.xxx.5 .

Funktioniert das nicht, weill die alte VPN-Lösung alle Anfragen "beantwortet"!? Wie kann ich das herausfinden?

Hoffe das hilft weiter... face-smile
Member: aqui
aqui Nov 17, 2015 updated at 13:20:25 (UTC)
Goto Top
Diese kann kein IPsec etc zu einzelnen PCs sondern "nur" Tunnel zu anderen Firewall-Geräten (Side by Side).
Das ist wie immer laienhafter Unsinn, denn wenn man UDP 500, UDP 4500 und das ESP Protokoll (IP Nummer 50) auf der Firewall erlaubt bzw. forwardet funktioniert auch das Forwarding von IPsec wunderbar. Mal ganz davon abgesehen das Palo Alto selber VPNs terminieren kann wie jede andere Firewall auch.
Aber egal....ist nicht das Thema hier.
Ich nutze Port 1194 TCP
Das ist per se schlecht ! Man sollte generell aus Performancegründen keine TCP Enkapsulierung nehmen für den VPN Tunnel sondern wenn möglich immer UDP !!
OpenVPN weist selber strikt darauf hin in seinem Setup Guide.
Besser also du verwendest hier UDP wie es auch in der Default Einstellung vorgegeben ist.

Da die Connection auf "Established" geht am Client sieht es nicht nach einem Firewall Problem aus sondern nach einer der OVPN Konfig selber.
Du solltest zuallererst mal die Encapsulation wieder auf UDP 1194 stellen und den Server mal isoliert vom restlichen 80.xxx.xxx.0 /29 er Netz an einen kleinen Testswitch hängen.
Hier klemmst du dich mit einem OVPN Client Laptop oder PC an dem du statisch mal eine 80.xxx.xxx.xxx /29 IP Adresse gibst und checkst vorab erstmal ob du überhaupt eine saubere OVPN Verbindung hinbekommst. (Client Logfile und Server !)
Dabei hilft dir das hiesige OVPN Tutorial:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Die OVPN Installationsschritte sind dabei identisch, denn die sind auf allen Plattformen vollkommen gleich.

Erst wenn die lokale Testverbindung sauber funktioniert, kannst du wieder an den Test via Firewall gehen.
Member: mikado90
mikado90 Nov 18, 2015 updated at 13:17:44 (UTC)
Goto Top
Hi! Danke für den Tipp mit dem lokalen Test > das ich da nicht gleich drauf gekommen bin...

Lokal funktioniert es. Ich kann auf alle Freigaben etc zugreifen, auch komme ich per Browser auf z.B. den Exchange etc... das Routing am OpenVPN Server scheint also zu funktionieren.

Nur wenn ich die PaloAlto dazwischen schalte funktioniert es nicht mehr... ich schaue mal ob ich an der aktuellen VPN-Lösung einen netzwerk-Dump erstellen kann, denn ich habe das Gefühl das die aktuelle VPN-LKösung die Anfragen "abfängt"...
Member: aqui
aqui Nov 18, 2015 updated at 18:35:34 (UTC)
Goto Top
das ich da nicht gleich drauf gekommen bin...
Manchmal sieht man halt den Baum vor lauter Wälder nicht face-wink
Lokal funktioniert es. Ich kann auf alle Freigaben etc zugreifen, auch komme ich per Browser auf z.B. den Exchange etc... das Routing am OpenVPN Server scheint also zu funktionieren.
Siehste..! Ist also die Palo Alto bzw. deine falsche Konfig dort der pöhse Puhmann !
Nur wenn ich die PaloAlto dazwischen schalte funktioniert es nicht mehr...
Klar da filterst du vermutlich UDP 1194 weg und dann nimmt das Unglück seinen Lauf. Oder dachtest du das sind Erdstrahlen unter der Palo Alto ??
Member: mikado90
mikado90 Nov 19, 2015 updated at 15:15:39 (UTC)
Goto Top
Ja dachte zuerst an Erdstrahlen, aber die sind es ja scheinbar nicht face-smile

In der PaloAlto route ich ja das komplette Netz 80.x.x.x.x.x/29 an den Lan-Anschluss 1/1.

Dieser Anschluss geht am Switch an den Port1 im Vlan DMZ.

In diesem VLAN befindet sich die aktuelle (alte) VPN-Lösung von Juniper.

Die Juniper hat die externe IP: 80.xxx.xxx.2

Im gleichen VLAN (DMZ) habe ich den OpenVPN-Server (neu) mit der IP 80.xxx.xxx.5 stehen.

Scheinbar werden aber alle Anfragen an die Juniper geroutet, nicht aber an den neuen VPN-Server - siehe DUMP aus der Juniper:

14:32:23.966728 00:1b:17:2e:ee:15 > 00:13:3b:12:54:71, ethertype IPv4 (0x0800), length 60: 212.xx.xxx.170.50309 > 80.xxx.xxx.xxx.1194: UDP, length 14
Member: mikado90
mikado90 Nov 20, 2015 updated at 10:42:04 (UTC)
Goto Top
Hi!

Gerade habe ich etwas gefunden:
http://wiki.openvpn.eu/index.php/Erster_Tunnel

Ich habe die Regel auf das externe Interface des OpenVPN Servers (80x.x.x.5) gesetzt (also 1194/udp). Richtig ist aber auf das interne Interface, also 172.16.x.x .

Ist das korrekt? Ich teste die konfig und melde mich...
Member: aqui
aqui Nov 20, 2015 at 13:33:21 (UTC)
Goto Top
Jetzt ist die Verwirrung komplett.... face-sad
Du hast:
  • Einen Internet Anschluss und ein kleines öffentliches Subnetz 80.x.x.x.x.x/29
  • Dieses eigene Subnetz 80.x.x.x.x.x/29 liegt an der Firewall an Port 1/1
  • FW Port 1/1 hängt an einem simplen Layer 2 VLAN an einen Switch
Ein klassisches Banal Szenario also für eine DMZ...
Nun müssen wir raten....
  • Vermutlich machst du KEIN NAT zwischen Internet und dem eigenen öffentl. Subnetz 80.x.x.x.x.x/29 an Port 1/1, richtig ?
  • Die Firewall hat aber mit Sicherheit Regeln für den Zugriff Internet auf dein 80.x.x.x.x.x/29 Segment, richtig ?
Diese Regeln sind aber nun essentiell.
Hier musst du FW Inbound am WAN/Internet Port von any den Zugriff auf die 80x.x.x.5 (OVPN Server) erlauben für Port UDP 1194 !

WAS genau ist bei dir das "interne" Interface ??? Davon hast du aktuell nichts gesagt oben ?! face-sad
Heisst das jetzt das der OVPN Server 2 Netzwerkkarten hat ??
Oder meinst du mit interem Interface das der PA Firewall ??
Für den Client Zugang von außen spielt das interne Interface keinerlei Rolle !! Klar, denn der VPN Client verbindet sich ja erstmal einzig und allein nur mit UDP 1194 mit dem OVPN Server um den VPN Tunnel zu etablieren.
Bei dir sieht es so aus als ob dein OVPN Server 2 Netzwerkkarten hat und du eine Karte im interne Netz betreibst mit der IP 172.16.x.100, richtig ?
Das ist insofern tödlich als das du damit deine DMZ natürlich konterkarierst !
Der OVPN Server, sollte er mal kompromietiert werden kann so ein Backdoor Router zw. Internet und deine internen Netz werden. Ein tödliches Design was kein verantwortlicher netzwerker so machen würde...das nur nebenbei.

Bedenke das die Client Absender IP IMMER die des internen OVPN Netzwerkes ist ! Welche das ist hast du uns ja leider nicht mitgeteilt face-sad
In deiner OVPN Server Konfig, die du uns ja leider aich nicht mitteilst MUSS auf alle Fälle folgender Routing Eintrag stehen:
push "route 172.16.x.0 255.255.255.0"
Damit eine Route des internen IP Netzes an den Client gesendet wird.
Bei aktiv eingeloggtem Client kannst du das dann auch immer mit route print in der Eingabeaufforderung checken sofern das Winblows basierte Clients sind.
Da du den OVPN Server DIREKT im lokalen Netzwerk hast sind weitere FW Regeln natürlich obsolet eben weil eine NIC des OVPN Servers ungeschützt in diesem Netzwerk hängt.
Damit musst du lediglich sicherstellen das die Firewall eingehende UDP 1194 Pakete aus dem Internet an das interne 80x.x.x.5 Interface des Servers weiterleitet werden.
Je nach OS des OVPN Servers kannst du das ganz einfach mit dem tcpdump Tool oder z.B. mit dem Wireshark dort verifizieren !

Weitere Infos erklärt dir auch das OVPN Tutorial hier im Forum:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Member: mikado90
mikado90 Nov 20, 2015 updated at 14:16:55 (UTC)
Goto Top
Hi! Danke für deine Mühe und Geduld.

Ja, der VPN Server besitzt 2 Netzwerkkarten, genau wie die Juniper-SA (alt) die getauscht werden soll.

1x Lan-Intern mit 172.x.x.216
1x Lan-DMZ mit 80.x.x.5

Internet > PaloAlto > "DMZ Subnetz 80.x.x.x.0/29" > Juniper SA (80.x.x.2 an Ext. Anschluss) und hier dann in das Server-Subnetz (Int. Anschluss mit 172.x.x.200)

Kann man hier auch Bilder hochladen? Dann könnte ich eine Skizze erstellen.
Member: aqui
aqui Nov 20, 2015 updated at 15:32:37 (UTC)
Goto Top
Kann man hier auch Bilder hochladen? Dann könnte ich eine Skizze erstellen.
Wie immer hilft da die FAQs lesen face-wink

Das Forum hat selber eine wunderbare Bilder Upload Funktion. Die kann dir auch nicht entgangen sein beim Erstellen deines Beitrags, es sei denn du hast Tomaten auf Selbigen ?!
Wenn man die FAQs liest ist es kinderleicht:
  • Deinen Originalthread mit "Meine Inhalte - Fragen" auswählen und auf "Bearbeiten" klicken !
  • Nun kannst du oben den Button "Bilder" nicht übersehen. Anklicken und dein Bild hochladen
  • Den nach dem Upload erscheinenden Bilder Link mit einem Rechtsklick und Copy und Paste sichern.
  • Diesen Bilder Link kannst du hier in jeglichen Text bringen ! Ja, auch Antworten..! Statt des Links kommt dann ...et voila.. Dein Bild im Browser!

Genauso wichtig ist aber die OVPN Konfig ! Grundlagen dazu wie gesagt hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Dort stehen auch alle Details zur Server Konfig. Die ist Plattform unabhängig, gilt also auch auf Server HW.
Member: mikado90
mikado90 Nov 23, 2015 updated at 10:14:48 (UTC)
Goto Top
Danke für deinen Hinweis, die Funktion "Bilder hochladen" hatte ich beim entsprechenden Kommentar erwartet, nicht beim "Thread-Start". Passt jetzt aber - Danke.
Member: mikado90
mikado90 Nov 23, 2015, updated at Dec 01, 2015 at 07:54:28 (UTC)
Goto Top
Hier die Konfiguration als Skizze:


Palo Alto Konfig Interfaces:

1e3591d1d9c52527d4d0cae57fc29a5c

Palo Alto Konfig NAT:

3017675a25a614c92bd6fbf26b5e5f18

Palo Alto Konfig Policy (hier zum Test "any" statt udp-1194 bzw "open-vpn"):

6f7ab55575f2b272b448726386a0b877

Palo Alto Konfig Policy-Based-Forwarding:

5e02aa7649fc85f0b18a314fb5f3f9af
Member: mikado90
mikado90 Nov 23, 2015 updated at 10:30:26 (UTC)
Goto Top
Ich möchte also zusätzlich zur aktuellen VPN-Lösung (Juniper) eine weitere mit Open-VPN integrieren.

Einen Ping von extern auf die 80.0.0.5 kann ich absetzen.

Lokal (siehe Tipp weiter oben) kann ich die Verbindung herstellen und auf das interne Netz zugreifen, DNS etc funktioniert auch wunderbar.

Nur sobald ich "hinter der Firewall" angeschlossen bin, bekomme ich am Client :

TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

Hinweis:
https://openvpn.net/index.php/open-source/faq/79-client/253-tls-error-tl ...

Firewall am Client ist deaktiviert, wie gesagt, lokal ohne Firewall funktioniert es mit diesem Client.

Wie stelle ich die passende Regel in der PaloAlto ein? Egal was ich versuche funktioniert es leider nicht...
Member: mikado90
mikado90 Nov 23, 2015 at 10:22:28 (UTC)
Goto Top
Server Konfig (Host = Debian 8):

;local a.b.c.d
port 1194

proto udp

dev tun

ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key  # This file should be kept secret

dh /etc/openvpn/dh2048.pem

server 10.8.0.0 255.255.255.0

ifconfig-pool-persist ipp.txt

push "route 172.16.0.0 255.255.254.0"  
push "route 172.16.1.0 255.255.254.0"  

push "dhcp-option DNS 172.16.0.11"  
push "dhcp-option DNS 172.16.0.12"  
push "dhcp-option DNS 208.67.222.222"  
push "dhcp-option DNS 208.67.220.220"  
push "dhcp-option DOMAIN lan.firmae.org"  

keepalive 10 120

comp-lzo

user nobody
group nogroup

persist-key
persist-tun

status openvpn-status.log

log-append /var/log/openvpn.log

verb 3
Member: mikado90
mikado90 Nov 23, 2015 at 10:40:52 (UTC)
Goto Top
Wenn ich eine Verbindung am openVPN CLient starte und gleichzeititg ein DUMP an der Juniper starte, sehe ich folgendes im DUMP-File:

11:34:03.380325 00:1b:17:2e:ee:15 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 80.0.0.5 (ff:ff:ff:ff:ff:ff) tell 80.0.0.5

Kann es sein das alle Anfragen an die Juniper geroutet werden!?
Member: mikado90
mikado90 Nov 23, 2015 at 11:07:17 (UTC)
Goto Top
Fehler-Log am Client:

Mon Nov 23 11:59:33 2015 NOTE: --user option is not implemented on Windows
Mon Nov 23 11:59:33 2015 NOTE: --group option is not implemented on Windows
Mon Nov 23 11:59:33 2015 OpenVPN 2.3.8 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Aug 4 2015
Mon Nov 23 11:59:33 2015 library versions: OpenSSL 1.0.1p 9 Jul 2015, LZO 2.08
Mon Nov 23 11:59:33 2015 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Mon Nov 23 11:59:33 2015 Need hold release from management interface, waiting...
Mon Nov 23 11:59:34 2015 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Mon Nov 23 11:59:34 2015 MANAGEMENT: CMD 'state on'
Mon Nov 23 11:59:34 2015 MANAGEMENT: CMD 'log all on'
Mon Nov 23 11:59:34 2015 MANAGEMENT: CMD 'hold off'
Mon Nov 23 11:59:34 2015 MANAGEMENT: CMD 'hold release'
Mon Nov 23 11:59:34 2015 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Nov 23 11:59:34 2015 UDPv4 link local: [undef]
Mon Nov 23 11:59:34 2015 UDPv4 link remote: [AF_INET]80.0.0.5:1194
Mon Nov 23 11:59:34 2015 MANAGEMENT: >STATE:1448276374,WAIT,,,
Mon Nov 23 12:00:34 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Nov 23 12:00:34 2015 TLS Error: TLS handshake failed
Mon Nov 23 12:00:34 2015 SIGUSR1[soft,tls-error] received, process restarting
Mon Nov 23 12:00:34 2015 MANAGEMENT: >STATE:1448276434,RECONNECTING,tls-error,,
Mon Nov 23 12:00:34 2015 Restart pause, 2 second(s)
Mon Nov 23 12:00:36 2015 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Nov 23 12:00:36 2015 UDPv4 link local: [undef]
Mon Nov 23 12:00:36 2015 UDPv4 link remote: [AF_INET]80.0.0.5:1194
Mon Nov 23 12:00:36 2015 MANAGEMENT: >STATE:1448276436,WAIT,,,
Mon Nov 23 12:01:36 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Nov 23 12:01:36 2015 TLS Error: TLS handshake failed
Mon Nov 23 12:01:36 2015 SIGUSR1[soft,tls-error] received, process restarting
Mon Nov 23 12:01:36 2015 MANAGEMENT: >STATE:1448276496,RECONNECTING,tls-error,,
Mon Nov 23 12:01:36 2015 Restart pause, 2 second(s)
Mon Nov 23 12:01:38 2015 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Nov 23 12:01:38 2015 UDPv4 link local: [undef]
Mon Nov 23 12:01:38 2015 UDPv4 link remote: [AF_INET]80.0.0.5:1194
Mon Nov 23 12:01:38 2015 MANAGEMENT: >STATE:1448276498,WAIT,,,
Member: aqui
aqui Nov 23, 2015 updated at 12:54:56 (UTC)
Goto Top
2 Dinge die noch unklar sind:
  • 1.) Du schreibst "Palo Alto Konfig NAT:"... Warum NAT ?? die 80er IP Adressen sind doch öffentliche IP Adressen. Du bekommst vermutlich ein kleines Sugnetz vom Provider. Das ist NAT dann vollkommen überflüssig. Die PA Konfig sagt auch nicht das das NAT ist !
  • 2.) In der OVPN Server Konfig steht push "route 172.16.0.0 255.255.254.0" und zusätzlich auch push "route 172.16.1.0 255.255.254.0". Warum ? Wenn du auf dem lokalen LAN 172.16.0.0 /23 mit einer 23 Bit Maske fährst wäre das völliger Schwachsinn, denn deine Subnatzmaske ist ja 23 Bit. Zeigt eher das du recht wenig Verständnis von IP Subnetting mitbringst face-sad

Folgende ToDos:
Ad 1.)
Kläre wirklich wasserdicht ob die PA hier wirklich NAT (Adress Translation) macht. Bei deiner 80er Adressierung wäre das kompletter Unsinn und müsste nicht sein. Es reichen normale FW Regeln hier.
Bei normalen Regeln reicht es wenn man UDP 1194 Traffic auf die 80.0.0.5 als Ziel passieren lässt, denn das ist der OVPN Tunnel. Mehr Ports benötigt OVPN nicht wenn man mal von UDP/TCP 53 (DNS) absieht was zusätzlich generell erlaubt sein sollte von allen 80er Adressen im DMZ Netz.
Sind die 80er Adressen nur Platzhalter hier im Posting und machst du tatsächlich NAT dann benötigst du 2 Regeln:
  • UDP 1194 Traffic muss passieren können bzw. erlaubt sein am WAN Port der PA
  • Es muss eine Port Forwarding Regel für UDP 1194 da sein die eingehenden UDP 1194 Traffic auf den OVPN Server mit der 80.0.0.5 forwardet !
Das sind die minimalsten Voraussetzungen damit es mit dem OVPN Server klappt.
Das setzt jetzt voraus das der Router VOR der PA Firewall jetzt keine Access Liste hat und auch kein NAT macht sondern rein transparent routet !
Ad 2.)
Dein Push Kommando ist IP technischer Blödsinn. Wenn du ein lokales Subnetz hast mit 172.16.0.0 /23 (also 255.255.254.0 Maske !) dann geht dein IP Subnetz von den Hostadressen von
Netzwerk Adresse: 172.16.0.0
Broadcast Adresse: 172.16.1.255
Host-IPs von: 172.16.0.1 bis: 172.16.1.254
Warum also dann dieser Blödsinn mit den 2 Push Kommandos ? Du musst doch lediglich nur ein einziges IP Netzwerk an die Clients propagieren und das ist dann das 172.16.0.0 /24.
Folglich reicht dann also push "route 172.16.0.0 255.255.254.0" völlig aus !
Check das mit dem NAT und korrigieren den Push Unsinn in deiner Konfig, dann klappt das auch !

Zusätzlich kannst du auch sehen das du noch einen TLS Handshake Error hast.
https://openvpn.net/index.php/open-source/faq/79-client/253-tls-error-tl ...
Zeigt also das du weiterhin noch ein Problem mit der Firewall oder der Client IP VPN Server Adresse hast !!
Die muss hier auf die 80.0.0.5 eingestellt sein oder wenn die PA tatsächlich NAT macht, dann muss dies die WAN Port IP Adresse der PA Firewall sein !!
Da du sagst die PA macht NAT und dein Client ohne NAT die direkte IP hat "UDPv4 link remote: [AF_INET]80.0.0.5:1194" kann das so nicht klappen, denn wenn NAT MUSS in der Client Konfig die WAN IP der Palo Alto (also WAN Port der PA wo der Router angeschlossen ist) stehen logischerweise !
Member: mikado90
mikado90 Nov 23, 2015 at 14:11:57 (UTC)
Goto Top
Hi! Das Subnetz ist - sorry hatte das sau dämmlich "unkenntlich" gemacht face-smile :

push "route 172.16.70.0 255.255.254.0"
push "route 172.16.80.0 255.255.254.0"
Member: mikado90
mikado90 Nov 23, 2015 updated at 15:16:57 (UTC)
Goto Top
NAT wird nur für den "Ersatz-DSL" Anschluss benötigt, ich habe diese Konfig wieder rausgenommen.

Hier die Regeln in der Firewall, mit denen es leider nicht funktioniert. Habe ich da noch etwas übersehen? "any" ändere ich später ab in "udp 1194". Die Firewall am Client ist deaktiviert.

48dc83292c78fc22a3db6db60ef5b946

Folgende Regeln habe ich (vor Jahren) für die Juniper erstellt und es funktioniert seitdem:

f228a47f58768f0381b92804671d36f5

Folgendes kann ich im Monitor der PaloAlto sehen:

6cbc3ed9d7d312fbc493a7ccff567308


Danke für deine Geduld und Mühe.
Member: mikado90
mikado90 Nov 27, 2015 at 12:34:52 (UTC)
Goto Top
Hi!

Endlich habe ich wieder Zeit zum testen face-wink .

Am Server bekomme ich per tcpdump Traffik angezeigt:

2374505fd6906fe71a8a7de5c68ee0b3

Leider jedoch immer noch keine Verbindung mit dem OpenVPN Server... Fehlt da eine Route zurück!?
Member: aqui
aqui Nov 27, 2015 updated at 12:39:24 (UTC)
Goto Top
Aktiviere im Zweifel einen Wireshark Sniffer oder nimm tcpdump und checke ob die UDP 1194 Pakete von extern sauber durch die Palo Alto auf deinen OVPN Server geforwardet werden.
Das ist das sicherste Tool um das zu checken.

Ok..sorry du warst etwas schneller oben... face-wink
OK, das sieht gut aus. Checke auch nochmal ob die outbound Pakete vom VPN Server auch beim Client landen und das die PA da outbound in richtung Client nix filtert !
Wenn das alles der Fall ist dann hast du vermutlich ein Problem bei der Zertifikatserstellung.
Oder...hast du parallel mal getestet ob du lokal, ohne Firewall fehlerlos eine VPN Verbindung vom Client auf den Server machen kannst ?
Meldet das Client Log dort dann einen "Success" ?
Member: mikado90
mikado90 Nov 27, 2015, updated at Dec 01, 2015 at 07:53:57 (UTC)
Goto Top
In der Palo Alto:

51b9d8b1449b18d257a22f91d0594dbd

13:17:52.299767 1c:6a:4:01:30 > 00:17:2e:ee:17, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 123, id 8506, offset 0, flags [none], proto: UDP (17), length: 42) 93.7.7.128.64720 > 80.0.0.5.1194: UDP, length 14
0x0000: 001b 172e ee17 1c6a 7a54 0130 0800 4500 .......jzT.0..E.
0x0010: 002a 213a 0000 7b11 4ed5 5dd3 0b80 5094 .*!:..{.N.]...P.
0x0020: 15cd fcd0 04aa 0016 cdb7 3847 6d34 adf5 ..........8Gm4..
0x0030: 6869 a500 0000 0000 0000 0000 hi..........
Member: mikado90
mikado90 Nov 27, 2015 at 12:44:51 (UTC)
Goto Top
Hi! Ja und jetzt bist du wieder schneller gewesen face-smile !

JA:
Oder...hast du parallel mal getestet ob du lokal, ohne Firewall fehlerlos eine VPN Verbindung vom Client auf den Server machen kannst ?
Meldet das Client Log dort dann einen "Success" ?

Lokal ohne Firewall funktioniert es und ich bekomme im Clienbt Log ein "Success". Auch kann ich dann auf alle Ressourcen zugreifen > per IP und FQDN.

Einzig die PaloAlto scheint hier was zu blocken...
Member: mikado90
mikado90 Nov 27, 2015 at 12:47:45 (UTC)
Goto Top
Client Log:
Fri Nov 27 13:39:17 2015 us=283304 OpenVPN 2.3.8 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Aug  4 2015
Fri Nov 27 13:39:17 2015 us=283304 library versions: OpenSSL 1.0.1p 9 Jul 2015, LZO 2.08
Enter Management Password:
Fri Nov 27 13:39:17 2015 us=283304 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Fri Nov 27 13:39:17 2015 us=283304 Need hold release from management interface, waiting...
Fri Nov 27 13:39:17 2015 us=782505 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Fri Nov 27 13:39:17 2015 us=891705 MANAGEMENT: CMD 'state on'  
Fri Nov 27 13:39:17 2015 us=891705 MANAGEMENT: CMD 'log all on'  
Fri Nov 27 13:39:17 2015 us=985306 MANAGEMENT: CMD 'hold off'  
Fri Nov 27 13:39:17 2015 us=985306 MANAGEMENT: CMD 'hold release'  
Fri Nov 27 13:39:18 2015 us=94506 crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by zu bytes
Fri Nov 27 13:39:18 2015 us=94506 LZO compression initialized
Fri Nov 27 13:39:18 2015 us=94506 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:3 ]
Fri Nov 27 13:39:18 2015 us=94506 Socket Buffers: R=[8192->8192] S=[8192->8192]
Fri Nov 27 13:39:18 2015 us=94506 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:143 ET:0 EL:3 AF:3/1 ]
Fri Nov 27 13:39:18 2015 us=94506 Local Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'  
Fri Nov 27 13:39:18 2015 us=94506 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'  
Fri Nov 27 13:39:18 2015 us=94506 Local Options hash (VER=V4): '41690919'  
Fri Nov 27 13:39:18 2015 us=94506 Expected Remote Options hash (VER=V4): '530fdded'  
Fri Nov 27 13:39:18 2015 us=94506 UDPv4 link local: [undef]
Fri Nov 27 13:39:18 2015 us=94506 UDPv4 link remote: [AF_INET]80.0.0.5:1194
Fri Nov 27 13:39:18 2015 us=94506 MANAGEMENT: >STATE:1448627958,WAIT,,,
Fri Nov 27 13:39:18 2015 us=94506 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:39:18 2015 us=94506 UDPv4 READ  from [undef]: DATA UNDEF len=-1
Fri Nov 27 13:39:20 2015 us=278510 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:39:24 2015 us=646517 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:39:32 2015 us=290531 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:39:48 2015 us=920160 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:40:18 2015 us=217011 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Nov 27 13:40:18 2015 us=217011 TLS Error: TLS handshake failed
Fri Nov 27 13:40:18 2015 us=217011 TCP/UDP: Closing socket
Fri Nov 27 13:40:18 2015 us=217011 SIGUSR1[soft,tls-error] received, process restarting
Fri Nov 27 13:40:18 2015 us=217011 MANAGEMENT: >STATE:1448628018,RECONNECTING,tls-error,,
Fri Nov 27 13:40:18 2015 us=217011 Restart pause, 2 second(s)
Fri Nov 27 13:40:20 2015 us=245015 Re-using SSL/TLS context
Fri Nov 27 13:40:20 2015 us=245015 crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by zu bytes
Fri Nov 27 13:40:20 2015 us=245015 LZO compression initialized
Fri Nov 27 13:40:20 2015 us=245015 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:3 ]
Fri Nov 27 13:40:20 2015 us=245015 Socket Buffers: R=[8192->8192] S=[8192->8192]
Fri Nov 27 13:40:20 2015 us=245015 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:143 ET:0 EL:3 AF:3/1 ]
Fri Nov 27 13:40:20 2015 us=245015 Local Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'  
Fri Nov 27 13:40:20 2015 us=245015 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'  
Fri Nov 27 13:40:20 2015 us=245015 Local Options hash (VER=V4): '41690919'  
Fri Nov 27 13:40:20 2015 us=245015 Expected Remote Options hash (VER=V4): '530fdded'  
Fri Nov 27 13:40:20 2015 us=245015 UDPv4 link local: [undef]
Fri Nov 27 13:40:20 2015 us=245015 UDPv4 link remote: [AF_INET]80.0.0.5:1194
Fri Nov 27 13:40:20 2015 us=245015 MANAGEMENT: >STATE:1448628020,WAIT,,,
Fri Nov 27 13:40:20 2015 us=245015 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:40:20 2015 us=245015 UDPv4 READ  from [undef]: DATA UNDEF len=-1
Fri Nov 27 13:40:22 2015 us=366619 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:40:26 2015 us=609826 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:40:34 2015 us=316240 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:40:50 2015 us=853269 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:41:20 2015 us=992522 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Nov 27 13:41:20 2015 us=992522 TLS Error: TLS handshake failed
Fri Nov 27 13:41:20 2015 us=992522 TCP/UDP: Closing socket
Fri Nov 27 13:41:20 2015 us=992522 SIGUSR1[soft,tls-error] received, process restarting
Fri Nov 27 13:41:20 2015 us=992522 MANAGEMENT: >STATE:1448628080,RECONNECTING,tls-error,,
Fri Nov 27 13:41:20 2015 us=992522 Restart pause, 2 second(s)
Fri Nov 27 13:41:22 2015 us=6524 Re-using SSL/TLS context
Fri Nov 27 13:41:22 2015 us=6524 crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by zu bytes
Fri Nov 27 13:41:22 2015 us=6524 LZO compression initialized
Fri Nov 27 13:41:22 2015 us=6524 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:3 ]
Fri Nov 27 13:41:22 2015 us=6524 Socket Buffers: R=[8192->8192] S=[8192->8192]
Fri Nov 27 13:41:22 2015 us=6524 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:143 ET:0 EL:3 AF:3/1 ]
Fri Nov 27 13:41:22 2015 us=6524 Local Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'  
Fri Nov 27 13:41:22 2015 us=6524 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'  
Fri Nov 27 13:41:22 2015 us=6524 Local Options hash (VER=V4): '41690919'  
Fri Nov 27 13:41:22 2015 us=6524 Expected Remote Options hash (VER=V4): '530fdded'  
Fri Nov 27 13:41:22 2015 us=6524 UDPv4 link local: [undef]
Fri Nov 27 13:41:22 2015 us=6524 UDPv4 link remote: [AF_INET]80.0.0.5:1194
Fri Nov 27 13:41:22 2015 us=6524 MANAGEMENT: >STATE:1448628082,WAIT,,,
Fri Nov 27 13:41:22 2015 us=6524 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:41:22 2015 us=6524 UDPv4 READ  from [undef]: DATA UNDEF len=-1
Fri Nov 27 13:41:24 2015 us=65727 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:41:28 2015 us=184134 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:41:36 2015 us=546749 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:41:52 2015 us=895578 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:42:22 2015 us=988031 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Nov 27 13:42:22 2015 us=988031 TLS Error: TLS handshake failed
Fri Nov 27 13:42:22 2015 us=988031 TCP/UDP: Closing socket
Fri Nov 27 13:42:22 2015 us=988031 SIGUSR1[soft,tls-error] received, process restarting
Fri Nov 27 13:42:22 2015 us=988031 MANAGEMENT: >STATE:1448628142,RECONNECTING,tls-error,,
Fri Nov 27 13:42:22 2015 us=988031 Restart pause, 2 second(s)
Fri Nov 27 13:42:24 2015 us=2032 Re-using SSL/TLS context
Fri Nov 27 13:42:24 2015 us=2032 crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by zu bytes
Fri Nov 27 13:42:24 2015 us=2032 LZO compression initialized
Fri Nov 27 13:42:24 2015 us=2032 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:3 ]
Fri Nov 27 13:42:24 2015 us=2032 Socket Buffers: R=[8192->8192] S=[8192->8192]
Fri Nov 27 13:42:24 2015 us=2032 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:143 ET:0 EL:3 AF:3/1 ]
Fri Nov 27 13:42:24 2015 us=2032 Local Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'  
Fri Nov 27 13:42:24 2015 us=2032 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'  
Fri Nov 27 13:42:24 2015 us=2032 Local Options hash (VER=V4): '41690919'  
Fri Nov 27 13:42:24 2015 us=2032 Expected Remote Options hash (VER=V4): '530fdded'  
Fri Nov 27 13:42:24 2015 us=2032 UDPv4 link local: [undef]
Fri Nov 27 13:42:24 2015 us=2032 UDPv4 link remote: [AF_INET]80.0.0.5:1194
Fri Nov 27 13:42:24 2015 us=2032 MANAGEMENT: >STATE:1448628144,WAIT,,,
Fri Nov 27 13:42:24 2015 us=2032 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:42:24 2015 us=2032 UDPv4 READ  from [undef]: DATA UNDEF len=-1
Fri Nov 27 13:42:26 2015 us=279636 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:42:30 2015 us=834844 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:42:38 2015 us=490859 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:42:54 2015 us=262486 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:43:25 2015 us=41340 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Nov 27 13:43:25 2015 us=41340 TLS Error: TLS handshake failed
Fri Nov 27 13:43:25 2015 us=41340 TCP/UDP: Closing socket
Fri Nov 27 13:43:25 2015 us=41340 SIGUSR1[soft,tls-error] received, process restarting
Fri Nov 27 13:43:25 2015 us=41340 MANAGEMENT: >STATE:1448628205,RECONNECTING,tls-error,,
Fri Nov 27 13:43:25 2015 us=41340 Restart pause, 2 second(s)
Fri Nov 27 13:43:27 2015 us=69344 Re-using SSL/TLS context
Fri Nov 27 13:43:27 2015 us=69344 crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by zu bytes
Fri Nov 27 13:43:27 2015 us=69344 LZO compression initialized
Fri Nov 27 13:43:27 2015 us=69344 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:3 ]
Fri Nov 27 13:43:27 2015 us=69344 Socket Buffers: R=[8192->8192] S=[8192->8192]
Fri Nov 27 13:43:27 2015 us=69344 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:143 ET:0 EL:3 AF:3/1 ]
Fri Nov 27 13:43:27 2015 us=69344 Local Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'  
Fri Nov 27 13:43:27 2015 us=69344 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'  
Fri Nov 27 13:43:27 2015 us=69344 Local Options hash (VER=V4): '41690919'  
Fri Nov 27 13:43:27 2015 us=69344 Expected Remote Options hash (VER=V4): '530fdded'  
Fri Nov 27 13:43:27 2015 us=69344 UDPv4 link local: [undef]
Fri Nov 27 13:43:27 2015 us=69344 UDPv4 link remote: [AF_INET]80.0.0.5:1194
Fri Nov 27 13:43:27 2015 us=69344 MANAGEMENT: >STATE:1448628207,WAIT,,,
Fri Nov 27 13:43:27 2015 us=69344 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:43:27 2015 us=69344 UDPv4 READ  from [undef]: DATA UNDEF len=-1
Fri Nov 27 13:43:29 2015 us=378148 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:43:33 2015 us=997756 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:43:41 2015 us=204969 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:43:57 2015 us=740998 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:44:28 2015 us=129851 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Nov 27 13:44:28 2015 us=129851 TLS Error: TLS handshake failed
Fri Nov 27 13:44:28 2015 us=129851 TCP/UDP: Closing socket
Fri Nov 27 13:44:28 2015 us=129851 SIGUSR1[soft,tls-error] received, process restarting
Fri Nov 27 13:44:28 2015 us=129851 MANAGEMENT: >STATE:1448628268,RECONNECTING,tls-error,,
Fri Nov 27 13:44:28 2015 us=129851 Restart pause, 2 second(s)
Fri Nov 27 13:44:30 2015 us=157855 Re-using SSL/TLS context
Fri Nov 27 13:44:30 2015 us=157855 crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by zu bytes
Fri Nov 27 13:44:30 2015 us=157855 LZO compression initialized
Fri Nov 27 13:44:30 2015 us=157855 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:3 ]
Fri Nov 27 13:44:30 2015 us=157855 Socket Buffers: R=[8192->8192] S=[8192->8192]
Fri Nov 27 13:44:30 2015 us=157855 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:143 ET:0 EL:3 AF:3/1 ]
Fri Nov 27 13:44:30 2015 us=157855 Local Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'  
Fri Nov 27 13:44:30 2015 us=157855 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'  
Fri Nov 27 13:44:30 2015 us=157855 Local Options hash (VER=V4): '41690919'  
Fri Nov 27 13:44:30 2015 us=157855 Expected Remote Options hash (VER=V4): '530fdded'  
Fri Nov 27 13:44:30 2015 us=157855 UDPv4 link local: [undef]
Fri Nov 27 13:44:30 2015 us=157855 UDPv4 link remote: [AF_INET]80.0.0.5:1194
Fri Nov 27 13:44:30 2015 us=157855 MANAGEMENT: >STATE:1448628270,WAIT,,,
Fri Nov 27 13:44:30 2015 us=157855 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:44:30 2015 us=157855 UDPv4 READ  from [undef]: DATA UNDEF len=-1
Fri Nov 27 13:44:32 2015 us=623659 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:44:36 2015 us=320866 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:44:44 2015 us=448480 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:45:00 2015 us=641308 UDPv4 WRITE [14] to [AF_INET]80.0.0.5:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Nov 27 13:45:11 2015 us=296127 TCP/UDP: Closing socket
Fri Nov 27 13:45:11 2015 us=296127 SIGTERM[hard,] received, process exiting
Fri Nov 27 13:45:11 2015 us=296127 MANAGEMENT: >STATE:1448628311,EXITING,SIGTERM,,
Fri Nov 27 13:45:11 2015 us=296127 PKCS#11: Terminating openssl
Fri Nov 27 13:45:11 2015 us=296127 PKCS#11: Removing providers
Fri Nov 27 13:45:11 2015 us=296127 PKCS#11: Releasing sessions
Fri Nov 27 13:45:11 2015 us=296127 PKCS#11: Terminating slotevent
Fri Nov 27 13:45:11 2015 us=296127 PKCS#11: Marking as uninitialized
Member: aqui
aqui Nov 27, 2015 at 12:48:39 (UTC)
Goto Top
Wieso eine 10er Route fürs OpenVPN ??
Das ist doch völliger Quatsch als next Hop da die öffentliche IP einzusetzen !
Die Firewall darf doch niemals auf die öffentliche IP routen !

Wenn die FW das default gateway für die lokalen Clients ist dann muss sie die 10.8.0.0er Pakete an das lokale LAN IP Interface des OVPN Servers routen ! Der hat doch ein Bein im lokalen LAN.
Die Route Einträge oben sind tödlich falsch.
Member: mikado90
mikado90 Nov 27, 2015 updated at 13:05:40 (UTC)
Goto Top
Mist klar *autsch* - Also so:

d80fdc8b7190923d289b11e860b479ac

Danke für deine Mühe!
Member: aqui
aqui Nov 27, 2015 at 13:12:40 (UTC)
Goto Top
So siehts besser aus face-wink
Member: mikado90
mikado90 Nov 27, 2015 at 13:17:06 (UTC)
Goto Top
Ja DANKE! Hmm... ich habe die Route aus vr-untrust auch noch gelöscht, leider funktioniert der Zugriff aber immer noch nicht...
Member: mikado90
mikado90 Nov 27, 2015, updated at Dec 01, 2015 at 07:53:41 (UTC)
Goto Top
Ich habe zum Testen ein weiteres System installiert ( gleiche IP 80.0.0.5) > natürlich den OpenVPN Server vorher abgeklemmt.

Policies: Unter Application habe ich natürlich "ftp" gewählt... ansonsten alles gleich


Auf diesen FTP-Server kann ich von extern perfekt zugreifen...

Kann das Problem an der Lan Konfig des VPN-Servers liegen?

Local:

iface eth0 inet static

address 172.16.0.2
netmask 255.255.255.0
gateway 172.16.0.254

DMZ:

iface eth1 inet static
address 80.0.0.5
netmask 255.255.255.248
gateway 80.0.0.1

Ich habe zwei Gateways in Verwendung!? Allerding funktioniert es lokal (also ohne Firewall dazwischen)...
Member: mikado90
mikado90 Nov 27, 2015 updated at 13:44:51 (UTC)
Goto Top
Ich habe jetzt das Gateway aus dem DMZ Netz entfernt, also die aktuelle konfig:

DMZ:

iface eth1 inet static
address 80.0.0.5
netmask 255.255.255.248

Anschließend den Server neugestartet - hier die Routen:

a424294dc1879eac0d3c61a21c561ce5

Ist das OK so?

So langsam fallen mir keine weiteren Schritte mehr ein...
Member: aqui
Solution aqui Nov 27, 2015, updated at Dec 01, 2015 at 07:53:21 (UTC)
Goto Top
Kann das Problem an der Lan Konfig des VPN-Servers liegen?
Ja, du hast auf BEIDEN Adaptern des VPN Servers ein Default Gateway !
Das geht so nicht, denn welches soll dein Server denn nun nehmen ?! Hier entscheidet die physische Bindungsreihenfolge das andere Gateway wird ignoriert und das ist dann tödlich.
Hier musst du zwingend das Default Gateway vom lokalen LAN löschen, denn damit muss der Server nicht kommunizieren.
Ich habe jetzt das Gateway aus dem DMZ Netz entfernt, also die aktuelle konfig:
Das wiederum war genau falsch, denn damit muss der server ja mit dem Internet kommunizieren. Da er nicht wissen kann mit welchem Zielnetz er mit dem Client kommunizieren muss muss hier zwingend das Default Gateway auf dem DMZ Netz konfiguriert werden, denn damit geht der Server ja ins Internet.
Wo es nicht gebraucht wird ist das lokale LAN !
Bzw. solltest du hier mehrere lokale IP Segmente haben dann musst du das mit dedizierten statischen Routen auf dem Server lösen.
Auf die Logik kommt man aber auch selber wenn man sich nur einmal ein wenig den Paket Flow vor Augen führt...
Ist das OK so?
Nein ! Siehe oben.
Wie schon mehrfach gesagt...Traceroute ist hier dein Freund !
Member: mikado90
mikado90 Dec 01, 2015 at 07:53:13 (UTC)
Goto Top
Hey "aqui" ! Danke für deine Hilfe und Geduld! Es funktioniert jetzt alles. Ich musste in der PALO eine "Override" für die Application erzeugen...

Echt vielen Danke für deine Mühe!!!
Member: aqui
aqui Dec 08, 2015 at 08:49:50 (UTC)
Goto Top
Immer gerne wieder.... face-smile
GermansolvedQuestionNetworks
Hotly discussed
AlexWishaHow to set up and configure a Linux GRE tunnelAlexWisha - 3 CommentsDaniEnd of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment