In einem Support Incident hatte ich in den letzten Wochen mit dem Problem zu k\u00e4mpfen, dass Mobile User, die sich per MUVPN (NCP IPSec Client) oder WatchGuard SSL-VPN-Client einw\u00e4hlen, zwar eine augenscheinlich stabile VPN-Verbindung stehen haben – aber trotzdem nicht auf Resourcen im lokalen Netzwerk zugreifen k\u00f6nnen.
Die Besonderheit hierbei war jedoch, dass der Zugriff unmittelbar nach der Einwahl m\u00f6glich war (z.B. Test per „ping -t“) – nach ein paar Sekunden jedoch pl\u00f6tzlich nicht mehr. Ein Vergleich der Routing Table des Einwahl-PCs („route print“) sofort nach der Einwahl und sp\u00e4ter nach dem Auftreten des Problems zeigt, dass die Einwahl-Routen in das lokale Netzwerk pl\u00f6tzlich verschwinden, wodurch nat\u00fcrlich nicht mehr auf die internen Resourcen zugegriffen werden kann… Umfangreiche Fehlersuche zeigte auf, dass das beschriebene Problem nur in Kombination aus bestimmten Faktoren auftritt. Reproduzierbar war das Problem insbesondere, wenn auf dem betroffenen Client-PC:<\/p>\n
Der Workaround<\/span>, der das Problem bei dem betreffenden Kunden zun\u00e4chst umschifft hat (ohne dabei jedoch das eigentliche Problem zu beheben) basiert darauf, unter Systemsteuerung > Netzwerkverbindungen<\/span> in dem virtuellen Netzwerkadapter, der von dem MUVPN-IPSec-Client (NCP) erzeugt wird, auf dem Tab „Authentication“ das H\u00e4kchen entfernen<\/span> bei Enable IEEE 802.1X Authentication<\/span>:<\/p>\n
![\"\"id=\"BLOGGER_PHOTO_ID_5535071752076649698\"](\"http:\/\/4.bp.blogspot.com\/_haYpXd-8uFA\/TNCGbrTT5OI\/AAAAAAAAAMk\/wUu8I8QS9f8\/s1600\/NIC-authentication-8021X.JPG\")
<\/a><\/p>\n