SSL-VPN nur mit iOS möglich

pointde · Beitrag von **pointde** » Sa 04.01.2014, 21:34

Obwohl die Subnetze und DNs gepusht werden komme ich nur mit dem iPhone auf die Geräte des Zielnetzes. Der Client auf dem Windows-PC (ob fest installiert oder portable) baut zwar die Verbingung auf, aber ich kann auf nichts zugreifen.

Code: Alles auswählen

Try to start OpenVPN connection SSL_RoW 
Sat Jan 04 20:42:04 2014 OpenVPN 2.2.2 Win32-MSVC++ [SSL] [LZO2] [PKCS11] built on Dec 15 2011
Sat Jan 04 20:42:14 2014 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Sat Jan 04 20:42:14 2014 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables

Sat Jan 04 20:42:14 2014 Control Channel MTU parms [ L:1541 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sat Jan 04 20:42:14 2014 Socket Buffers: R=[8192->8192] S=[8192->8192]
Sat Jan 04 20:42:14 2014 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4 ET:0 EL:0 ]
Sat Jan 04 20:42:14 2014 Local Options hash (VER=V4): '3514370b'
Sat Jan 04 20:42:14 2014 Expected Remote Options hash (VER=V4): '239669a8'
Sat Jan 04 20:42:14 2014 UDPv4 link local: [undef]
Sat Jan 04 20:42:14 2014 UDPv4 link remote: 00.000.xxx.xxx:1194
Sat Jan 04 20:42:14 2014 TLS: Initial packet from xx.xx.xx.236:1194, sid=2af67c32 65895478
Sat Jan 04 20:42:14 2014 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat Jan 04 20:42:15 2014 VERIFY OK: depth=1, /C=DE/ST=xxx/L=xxx/O=xxx/CN=Server_CA/emailAddress=xxx@test.de
Sat Jan 04 20:42:15 2014 VERIFY OK: depth=0, /C=DE/ST=xxx/L=xxx/O=xxx/OU=EDV/CN=Server-Cert/emailAddress=xxx@test.de
Sat Jan 04 20:42:15 2014 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Jan 04 20:42:15 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 04 20:42:15 2014 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Jan 04 20:42:15 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 04 20:42:15 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sat Jan 04 20:42:15 2014 [Server-Cert] Peer Connection Initiated with xx.xx.xx.xx:1194
Sat Jan 04 20:42:18 2014 SENT CONTROL [Server-Cert]: 'PUSH_REQUEST' (status=1)
Sat Jan 04 20:42:18 2014 PUSH: Received control message: 'PUSH_REPLY,route 192.168.20.0 255.255.255.0,route-gateway 192.168.250.1,topology subnet,ping 10,ping-restart 120,ifconfig 192.168.250.3 255.255.255.0'
Sat Jan 04 20:42:18 2014 OPTIONS IMPORT: timers and/or timeouts modified
Sat Jan 04 20:42:18 2014 OPTIONS IMPORT: --ifconfig/up options modified
Sat Jan 04 20:42:18 2014 OPTIONS IMPORT: route options modified
Sat Jan 04 20:42:18 2014 OPTIONS IMPORT: route-related options modified
Sat Jan 04 20:42:18 2014 ROUTE default_gateway=192.168.2.1
Sat Jan 04 20:42:18 2014 TAP-WIN32 device [LAN-Verbindung 2] opened: \\.\Global\{A9C3BA1F-D821-4CE7-A988-BDA7ACFC7046}.tap
Sat Jan 04 20:42:18 2014 TAP-Win32 Driver Version 9.9 
Sat Jan 04 20:42:18 2014 TAP-Win32 MTU=1500
Sat Jan 04 20:42:18 2014 Set TAP-Win32 TUN subnet mode network/local/netmask = 192.168.250.0/192.168.250.3/255.255.255.0 [SUCCEEDED]
Sat Jan 04 20:42:18 2014 Notified TAP-Win32 driver to set a DHCP IP/netmask of 192.168.250.3/255.255.255.0 on interface {A9C3BA1F-D821-4CE7-A988-BDA7ACFC7046} [DHCP-serv: 192.168.250.254, lease-time: 31536000]
Sat Jan 04 20:42:18 2014 Successful ARP Flush on interface [30] {A9C3BA1F-D821-4CE7-A988-BDA7ACFC7046}
Sat Jan 04 20:42:20 2014 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
Sat Jan 04 20:42:20 2014 C:\WINDOWS\system32\route.exe ADD 192.168.20.0 MASK 255.255.255.0 192.168.250.1
 OK!
Sat Jan 04 20:42:20 2014 Initialization Sequence Completed
Sat Jan 04 20:42:18 2014 SENT CONTROL [Server-Cert]: 'PUSH_REQUEST' (status=1)
Sat Jan 04 20:42:18 2014 PUSH: Received control message: 'PUSH_REPLY,route 192.168.20.0 255.255.255.0,route-gateway 192.168.250.1,topology subnet,ping 10,ping-restart 120,ifconfig 192.168.250.3 255.255.255.0'
Sat Jan 04 20:42:18 2014 OPTIONS IMPORT: timers and/or timeouts modified
Sat Jan 04 20:42:18 2014 OPTIONS IMPORT: --ifconfig/up options modified
Sat Jan 04 20:42:18 2014 OPTIONS IMPORT: route options modified
Sat Jan 04 20:42:18 2014 OPTIONS IMPORT: route-related options modified
Sat Jan 04 20:42:18 2014 ROUTE default_gateway=192.168.2.1
Sat Jan 04 20:42:18 2014 TAP-WIN32 device [LAN-Verbindung 2] opened: \\.\Global\{A9C3BA1F-D821-4CE7-A988-BDA7ACFC7046}.tap
Sat Jan 04 20:42:18 2014 TAP-Win32 Driver Version 9.9 
Sat Jan 04 20:42:18 2014 TAP-Win32 MTU=1500
Sat Jan 04 20:42:18 2014 Set TAP-Win32 TUN subnet mode network/local/netmask = 192.168.250.0/192.168.250.3/255.255.255.0 [SUCCEEDED]
Sat Jan 04 20:42:18 2014 Notified TAP-Win32 driver to set a DHCP IP/netmask of 192.168.250.3/255.255.255.0 on interface {A9C3BA1F-D821-4CE7-A988-BDA7ACFC7046} [DHCP-serv: 192.168.250.254, lease-time: 31536000]
Sat Jan 04 20:42:18 2014 Successful ARP Flush on interface [30] {A9C3BA1F-D821-4CE7-A988-BDA7ACFC7046}

Beitrag von **Erik** » So 05.01.2014, 14:57

Wie erfolgt denn der Zugriff? Über die IP? Über den NETBIOS-Namen? Über den FQDN?
Windows ist bekannt dafür, die DNS-Config nicht zu übernehmen. Klappt denn der Ping auf einen Host hinter dem Tunnel?

pointde · Beitrag von **pointde** » So 05.01.2014, 15:52

Es klappt kein Ping auf eine IP-Adresse aus dem ZielNetz

Code: Alles auswählen

Ethernet-Adapter LAN-Verbindung:

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : TAP-Win32 Adapter V9
   Physische Adresse . . . . . . . . : 00-FF-24-24-23-BB
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::4e4:1f06:77a9:b32%12(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.250.2(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Sonntag, 5. Januar 2014 14:54:06
   Lease läuft ab. . . . . . . . . . : Montag, 5. Januar 2015 14:54:06
   Standardgateway . . . . . . . . . :
   DHCP-Server . . . . . . . . . . . : 192.168.250.254
   DHCPv6-IAID . . . . . . . . . . . : 201391908
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-19-47-76-D6-60-A4-4C-37-4A-C5

   DNS-Server  . . . . . . . . . . . : 192.168.20.254
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

VPN-->Globale Einstellungen-->NAT-Traversal aktivieren:Ein
Name-Server-->Primärer Server-->192.168.20.254

VPN-->SSL-VPN-->SSL-RoW-->Subnetze übermitteln-->192.168.20.0/24 -->Erweitert-->DNS übermitteln:EIN
Firewall-->Portfiler-->SSL---->internal-Network---->Any---->Acceppt

Korrektur: Auch mit dem iPhone komme ich nicht an das IP-Netzwerk 192.168.20.0. Der Tunnel wird auch hier einwandfrei aufgebaut.

Beitrag von **Erik** » Mo 06.01.2014, 11:03

Aha. Das verändert ja einiges...
Prüfen Sie doch bitte mal auf dem Host, den Sie erreichen wollen, ob
a) der ein korrektes Default-GW hat (nämlich die interne IP der Firewall)
b) eine evtl auf diesem Host installierte Firewall die Anfragen verwirft

pointde · Beitrag von **pointde** » Mo 06.01.2014, 11:10

a:) ja, der bekommt via DHCP alles von der Firewall
b:) keine Software Firewall oder ähnliches

Petasch · Beitrag von **Petasch** » Mo 06.01.2014, 12:17

und das Netzwerkobjekt ist auch in der richtigen Zone?

pointde · Beitrag von **pointde** » Mo 06.01.2014, 12:32

Beitrag von **Christian E.** » Mo 06.01.2014, 13:58

Hallo,
hat das Netzwerkobjekt auch die korrekte Netzwerkmaske?

pointde · Beitrag von **pointde** » Mo 06.01.2014, 14:52

ebenfalls ja!

Beitrag von **Erik** » Mo 06.01.2014, 16:13

Dann prüfen Sie mal mittels tcpdump, ob die Pakete überhaupt ins interne Netzwerk geschickt werden. Melden Sie sich dazu als root-User an einer SSH-Konsole der Firewall an und führen dann aus:

Code: Alles auswählen

# tcpdump -i eth1 -nnp proto 1

"eth1" ersetzen Sie durch den Namen des internen Interfaces. Jetzt starten Sie einen Ping durch den Tunnel. Mögliche Ausgabe:

Überhaupt keine Ausgabe
Führen Sie aus:

Code: Alles auswählen

# tcpdump -i eth0 -nnp port 1194

"eth0" ist hierbei das externe Interface. Sie sollten - sofern der Ping an der Firewall ankommt - UDP-pakete sehen, die entweder 101 oder 125 Byte groß sind. Ist das nicht der Fall, macht der Client Mist. Sehen Sie hingegen die beschriebenen Pakete, muss ein Fehler im Regelwerk vorliegen.

Es sind nur "icmp-echo-request"-Pakete sichtbar
Problem mit dem Host, den Sie erreichen wollen (Default-Route, Software/Windows-Firewall)

Es sind sowohl "icmp-echo-request"-, als auch "icmp-echo-response"-Pakete sichtbar
Mögliches Problem beim Rückrouting in den Tunnel. Kontrollieren Sie evtl eingetragene Rule- oder Source-Routen. Sollten Sie eine Überschneidung feststellen, fügen Sie bei der Regel "SSLVPN-Netz > Internes Netz > DIENST" das Flag "Rule-Routing" hinzu und setzen es auch "tun0"