VPN im LAN funktioniert nicht

[achberger]

Hallo,

wir haben seit geraumer Zeit das Problem, dass Client, die sich aus dem LAN per VPN verbinden, durch diese Verbindung keinen Traffic bekommen. Der Tunnel steht und meldet keine Fehler.

Das Problem besteht sowohl mit IPSecuritas unter OS X, beim iPhone, als auch bei diversen Clients auf Windows. Einen Konfigurationsfehler würde ich also ausschließen.

Zur Erläuterung:
Wir nutzen ein Interface des Intranators, um Gästen WLAN zur Verfügung zu stellen, die keine Verbindung in unser Intranet erhalten sollen. Mitarbeiter mit VPN-Zugriff sollen diese WLAN-Verbindung jedoch nutzen können, um per VPN ins Intranet zu kommen.

Leider kann ich nicht eingrenzen, seit wann das Problem besteht und weiss auch nicht wirklich, wo ich nach Fehlern suchen soll.


Viele Grüße
Jürgen Achberger

[Thomas Jarosch]

Guten Morgen Herr Achberger,

meine erste Vermutung würde Richtung Firewall auf dem Client bzw. Firewall auf dem Intranator für das WLAN Netz gehen. Am besten Sie öffnen ein Support-Ticket und schicken einen Screenshot der WLAN-Firewallregeln vom Intranator.

Herzliche Grüße,
Thomas Jarosch

[achberger]

Hallo Herr Jarosch,

bevor ich das Ticket aufmache, habe ich jetzt noch mal per tcpdump geschaut, ob etwas durch den Tunnel beim Intranator ankommt:

[root@intranator ~]# tcpdump -vvv -i any -n 'src host 172.20.x.x (vpn Client Adresse)'
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
13:15:18.233319 IP (tos 0x0, ttl 64, id 21851, offset 0, flags [DF], proto TCP (6), length 48)
172.20.x.x (vpn Client Adresse).49324 > 213.23.x.x.imaps: Flags [S], cksum 0x57b8 (correct), seq 3299395519, win 65535, options [mss 1240,sackOK,eol], length 0
13:15:22.296986 IP (tos 0x0, ttl 64, id 52350, offset 0, flags [none], proto ICMP (1), length 84)
172.20.x.x (vpn Client Adresse) > 213.23.x.x (LAN DMZ): ICMP echo request, id 28161, seq 0, length 64
13:15:23.297042 IP (tos 0x0, ttl 64, id 47912, offset 0, flags [none], proto ICMP (1), length 84)
172.20.x.x (vpn Client Adresse) > 213.23.x.x (LAN DMZ): ICMP echo request, id 28161, seq 1, length 64
13:15:24.297000 IP (tos 0x0, ttl 64, id 8981, offset 0, flags [none], proto ICMP (1), length 84)
172.20.x.x (vpn Client Adresse) > 213.23.x.x (LAN DMZ): ICMP echo request, id 28161, seq 2, length 64
13:15:25.297057 IP (tos 0x0, ttl 64, id 1403, offset 0, flags [none], proto ICMP (1), length 84)
172.20.x.x (vpn Client Adresse) > 213.23.x.x (LAN DMZ): ICMP echo request, id 28161, seq 3, length 64
13:15:26.241915 IP (tos 0x0, ttl 64, id 30996, offset 0, flags [DF], proto TCP (6), length 48)
172.20.x.x (vpn Client Adresse).49324 > 213.23.84.24.imaps: Flags [S], cksum 0x57b8 (correct), seq 3299395519, win 65535, options [mss 1240,sackOK,eol], length 0
13:15:26.297015 IP (tos 0x0, ttl 64, id 28941, offset 0, flags [none], proto ICMP (1), length 84)
172.20.x.x (vpn Client Adresse) > 213.23.x.x (LAN DMZ): ICMP echo request, id 28161, seq 4, length 64
13:15:27.296973 IP (tos 0x0, ttl 64, id 13689, offset 0, flags [none], proto ICMP (1), length 84)
172.20.x.x (vpn Client Adresse) > 213.23.x.x (LAN DMZ): ICMP echo request, id 28161, seq 5, length 64
13:15:30.853498 IP (tos 0x0, ttl 64, id 31490, offset 0, flags [none], proto ICMP (1), length 84)
172.20.x.x (vpn Client Adresse) > 172.20.x.y (LAN 2): ICMP echo request, id 28417, seq 0, length 64
13:15:31.853455 IP (tos 0x0, ttl 64, id 57161, offset 0, flags [none], proto ICMP (1), length 84)
172.20.x.x (vpn Client Adresse) > 172.20.x.y (LAN 2): ICMP echo request, id 28417, seq 1, length 64
13:15:32.853462 IP (tos 0x0, ttl 64, id 63522, offset 0, flags [none], proto ICMP (1), length 84)
172.20.x.x (vpn Client Adresse) > 172.20.x.y (LAN 2): ICMP echo request, id 28417, seq 2, length 64
13:15:33.853419 IP (tos 0x0, ttl 64, id 55579, offset 0, flags [none], proto ICMP (1), length 84)
172.20.x.x (vpn Client Adresse) > 172.20.x.y (LAN 2): ICMP echo request, id 28417, seq 3, length 64
13:15:34.853377 IP (tos 0x0, ttl 64, id 4381, offset 0, flags [none], proto ICMP (1), length 84)
172.20.x.x (vpn Client Adresse) > 172.20.x.y (LAN 2): ICMP echo request, id 28417, seq 4, length 64
13:15:35.853434 IP (tos 0x0, ttl 64, id 3423, offset 0, flags [none], proto ICMP (1), length 84)
172.20.x.x (vpn Client Adresse) > 172.20.x.y (LAN 2): ICMP echo request, id 28417, seq 5, length 64
13:15:42.257255 IP (tos 0x0, ttl 64, id 13335, offset 0, flags [DF], proto TCP (6), length 48)
172.20.x.x (vpn Client Adresse).49324 > 213.23.84.24.imaps: Flags [S], cksum 0x57b8 (correct), seq 3299395519, win 65535, options [mss 1240,sackOK,eol], length 0



Hier die Pings dazu:

achberger-mac:~ achberger$ ping 213.23.x.x (LAN DMZ)
PING 213.23.x.x (LAN DMZ) (213.23.x.x (LAN DMZ)): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
^C
--- 213.23.x.x (LAN DMZ) ping statistics ---
6 packets transmitted, 0 packets received, 100.0% packet loss
achberger-mac:~ achberger$ ping 172.20.x.y (LAN 2)
PING 172.20.x.y (LAN 2) (172.20.x.y (LAN 2)): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4


Ich selbst befinde bin 172.20.x.z (LAN 1), bzw. 172.20.x.x (VPN-Client Adresse)

Die FW-Regel für 172.20.x.z (LAN 1) lautet Vollzugriff auf alle Netze (Quelle: Alle, Ziel: Alle, Dienst: Alle, Aktion: Accept), Automatische Antwortregel.
Die FW-Regel für 172.20.x.x (VPN-Client Adresse) lautet Vollzugriff auf (213.23.x.x (LAN DMZ)) und 172.20.x.y (LAN 2) mit Automatischer Antwortregel.

Nachtrag: In /var/log/messages sind keine Einträge für 172.20.x.x (VPN-Client Adresse) zu finden. Deshalb gehe ich davon aus dass die Firewall nicht eingreift.


Ping scheinen also durch den Tunnel anzukommen, aber es gibt keine Antwort.

Hilft uns das weiter?


Viele Grüße
Jürgen Achberger

[bjoerns]

Hallo,

Ping scheinen also durch den Tunnel anzukommen, aber es gibt keine Antwort.

Hilft uns das weiter?

man sollte mal überprüfen, ob das Paket dann auf dem Zielrechner ankommt. Oder ist der Zielrechner in diesem Fall der Intranator, das konnte ich jetzt nicht genau sehen. Ansonsten auch mal testen, wie es sich mit einem Ping aus dem WLAN Netz über VPN an die interne Intranator LAN IP verhält.

MFG Björn

[achberger]

Hallo Björn,

ich habe das mal getestet. Interessanterweise kommen die Ping-Pakete bei dem Intranator-Interface an, es wird jedoch keine Antwort registriert.

Hier der Auszug aus der Konsole:

[root@intranator ~]# tcpdump -vvv -i any -n 'src host 172.20.vpn-ip and dst host 172.20.intranator-interface'
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
19:08:37.720889 IP (tos 0x0, ttl 64, id 27942, offset 0, flags [none], proto ICMP (1), length 84)
172.20.vpn-ip > 172.20.intranator-interface: ICMP echo request, id 1294, seq 0, length 64
19:08:38.720952 IP (tos 0x0, ttl 64, id 32380, offset 0, flags [none], proto ICMP (1), length 84)
172.20.vpn-ip > 172.20.intranator-interface: ICMP echo request, id 1294, seq 1, length 64
19:08:39.720956 IP (tos 0x0, ttl 64, id 8296, offset 0, flags [none], proto ICMP (1), length 84)
172.20.vpn-ip > 172.20.intranator-interface: ICMP echo request, id 1294, seq 2, length 64
19:08:40.721014 IP (tos 0x0, ttl 64, id 59180, offset 0, flags [none], proto ICMP (1), length 84)
172.20.vpn-ip > 172.20.intranator-interface: ICMP echo request, id 1294, seq 3, length 64
19:08:41.721072 IP (tos 0x0, ttl 64, id 64792, offset 0, flags [none], proto ICMP (1), length 84)
172.20.vpn-ip > 172.20.intranator-interface: ICMP echo request, id 1294, seq 4, length 64
^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel


[root@intranator ~]# tcpdump -vvv -i any -n 'src host 172.20.intranator-interface and dst host 172.20.vpn-ip'
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel



172.20.vpn-ip:~ achberger$ ping 172.20.intranator-interface
PING 172.20.intranator-interface (172.20.intranator-interface): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
^C
--- 172.20.intranator-interface ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss

Der Ping ging auf ein LAN-Interface, dessen Netz per VPN verbunden ist, nicht auf mein LAN-Standardgateway.

Die VPN-Verbindung wird mit dem Provider-Interface hergestellt. (Gleiche VPN-konfiguration wie von ausserhalb, die ja funktioniert). Sobald ich meine VPN-Verbindung trenne, funktioniert der selbe Ping wieder.

Jetzt wird's interessant:
Ich habe mal Testweise in IPSecuritas mein Intranet-LAN-Standardgateway als Endpunkt für die VPN-Verbindung eingetragen und siehe da, ich bekomme plötzlich Traffic durch den Tunnel. Ich bin mir jedoch sicher, dass ich früher ohne Schwierigkeiten die selbe Konfiguration innerhalb des LAN und von Extern benutzt habe. Ich kann mich erinnern, dass bei irgend einem Update von Umbau des gesamten VPN-System die Rede war? Könnte da der Hund begraben sein?


Viele Grüße
Jürgen

[Gerd von Egidy]

Hallo,

[root@intranator ~]# tcpdump -vvv -i any -n 'src host 172.20.vpn-ip and dst host 172.20.intranator-interface'

Bitte beachten Sie, daß tcpdump prinzipbedingt nur die eingehenden VPN-Pakete sehen kann. Alles, was verschlüsselt in ein VPN gesendet wird (also auch die Antworten auf Ihre Pings), sind im tcpdump nicht mehr unverschlüsselt sichtbar. Sie können nur noch verschlüsselte ESP-Pakete sehen. Dafür müssen Sie natürlich einen passenden Filter wählen.

Filtern Sie im tcpdump z.B. mal nur nach ESP-Paketen.

Ich habe mal Testweise in IPSecuritas mein Intranet-LAN-Standardgateway als Endpunkt für die VPN-Verbindung eingetragen und siehe da, ich bekomme plötzlich Traffic durch den Tunnel. Ich bin mir jedoch sicher, dass ich früher ohne Schwierigkeiten die selbe Konfiguration innerhalb des LAN und von Extern benutzt habe. Ich kann mich erinnern, dass bei irgend einem Update von Umbau des gesamten VPN-System die Rede war?

Das VPN-System wird im Intranator kontinuierlich weiterentwickelt. Vor einiger Zeit haben wir z.B. Unterstützung für iPhones eingeführt, momentan arbeiten wir an einer Funktion für NAT im VPN um IP-Konflikte lösen zu können.

Herzliche Grüße,

v. Egidy

[achberger]

Hallo Herr v. Egidy,

danke für den Hinweis bzgl. VPN-Traffic und TCP-Dump.

Da der VPN-Durchsatz abhängig von der verwendeten Zieladresse der Gegenstelle funktioniert bzw. nicht funktioniert, gehe ich mal davon aus, dass kein Konfigurationsproblem vorliegt, sondern das aktuelle VPN-System verlangt, dass die VPN-Verbindung mit dem Intranet-LAN-Interface (also intranator.net.lan anstelle provider-interface.foo.com) hergestellt wird, wenn ich mich im Intranet befinde.

Es wäre klasse, wenn zukünftige Versionen diese Unterscheidung überflüssig machen würden.


Danke und viele Grüße
Jürgen Achberger

[bjoerns]

Hallo,

Da der VPN-Durchsatz abhängig von der verwendeten Zieladresse der Gegenstelle funktioniert bzw. nicht funktioniert, gehe ich mal davon aus, dass kein Konfigurationsproblem vorliegt, sondern das aktuelle VPN-System verlangt, dass die VPN-Verbindung mit dem Intranet-LAN-Interface (also intranator.net.lan anstelle provider-interface.foo.com) hergestellt wird, wenn ich mich im Intranet befinde.

das heisst also, dass die Mitarbeiter 2 konfigurierte VPN-Verbindungen benötigen. Einmal um von extern zuzugreifen und einmal um über das WLAN von intern zuzugreifen.

Vielen Dank für die Rückmeldung. Wir sind natürlich stets bemüht, den Intranator weiter zu entwickeln und den Bedürftnisse unserer Kunden anzupassen.

Ich werde dieses Problem dann mal an den VPN-Meister weitergeben, vielleicht kann man da noch was machen.

MFG Björn