Tag Archives: PPTP-VPN

Probleme mit PPTP-VPN

4 Comments

In der letzten Zeit stolpere ich häufiger über Probleme mit Mobile User VPN über PPTP, die nach einiger Zeit im laufenden Betrieb oder nach einer Hardware-Migration auftreten. Die WatchGuard verweigert einfach die PPTP-Einwahl, obwohl sich an der Konfiguration, Benutzername, Kennwort und Client-Einstellungen nichts geändert hat. Wenn auch ein Reboot der WatchGuard nicht weiter hilft, hat sich folgender Trick bewährt:

  • Aktuelle Konfigurationsdatei (XML) unter einem anderen Namen sichern.
  • VPN > Mobile VPN > PPTP… komplett deaktivieren (Häkchen entfernen).
  • Eventuelle Firewall-Regeln löschen, die auf Basis der Gruppe “PPTP-Users” geschrieben waren.
  • “Save to Firebox”
  • File > Open > Configuration File (die zuvor auf die Seite gelegte Version öffnen)
  • “Save to Firebox”

Nun sollte die VPN-Einwahl per PPTP wieder funktionieren. Eine Erklärung dafür habe ich nicht.

Begrenzter Zeichensatz bei Active Directory Authentication

Comment

Puuuuh, nach mehr als einem halben Jahr komme ich endlich mal wieder dazu, hier einen Beitrag zu schreiben. Ich will nicht klagen, es waren einfach sehr viele und anspruchsvolle Projekte in den letzten Monaten. In den nächsten Wochen hoffe ich nun, hier wieder einige hilfreiche Postings schreiben zu können.

Ich fange mit einem “alten Schuh” an, allerdings in einer etwas anderen Ausprägung. Ich habe bereits ja empfohlen, sich in der WatchGuard XML Konfigurationsdatei, und insbesondere bei Passwörtern, Pre-Shared Keys etc. auf den Zeichensatz US-ASCII 7 zu beschränken, d.h. also insbesondere auf die Verwendung von äöüß und Sonderzeichen zu verzichten. Ich empfehle sogar, Kennwörter etc. gänzlich nur aus den klassischen Buchstaben A-Z, a-z und den Ziffern 0-9 zu bilden. Ganz ohne Sonderzeichen, lieber ein paar Stellen mehr…

Wenn nun User Authentication gegenüber Active Directory im Spiel ist, sollte diese Grundregel auch beherzigt werden, wenn die User ihre AD/Windows-Kennwörter festlegen. Ein Kunde berichtete von MUVPN-Einwahl-Problemen bei einem bestimmten User. Dieser hatte ein €-Zeichen in seinem Windows-Kennwort. Die Einwahl schlug fehl. Nach Änderung des AD/Windows-Kennworts (ohne €-Zeichen) war die Einwahl erfolgreich!

Der Kunde hat mir freundlicherweise eine Liste von Zeichen geschickt, die in einem AD/Windows-Kennwort vorkommen dürfen, damit eine MUVPN-Einwahl / User Authentication erfolgreich ist:

!#$%&()*+,-.0123456789:;<=>@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]_abcdefghijklmnopqrstuvwxyz{} und das “Leerzeichen”…

Diese Einschränkung dürfte dann auch gelten, wenn die Einwahl bzw. Authentication per PPTP-VPN (i.V. mit RADIUS), SSL-VPN (AD oder RADIUS) und auch in Verbindung mit Two-Factor Authentication Systemen wie VASCO oder RSA gegenüber AD erfolgt!

Bugfixes in WatchGuard WSM und Fireware XTM 11.1

Comment

Die Versionen Fireware XTM v11.1 und WSM v11.1 beheben eine Reihe von Bugs und Known Issues früherer Versionen. Diese Aufstellung wurde den aktuellen Release Notes der Version 11.1 entnommen. Obwohl man aufgrund der Vielzahl eventuell auf den Gedanken kommen könnte, dass das Produkt sehr fehlerlastig ist (bzw. war), sehe ich diese offene Kommunikation hingegen sehr positiv. Die meisten anderen Hersteller geben kaum vergleichbare Informationen heraus, sondern werkeln eher im Hintergrund. Zudem zeigt sich, dass das Produkt “lebt” und intensiv weiterentwickelt wird. Auch schon in den Versionen 11.0.1 und 11.0.2 war das Produkt ausreichend stabil, auch wenn ich meinen Kunden anfangs eher zur Zurückhaltung geraten habe!

General

  • The WSM Quick Setup Wizard now allows you to enter a feature key that contains a model upgrade for Edge e-Series. [40405]

  • Fireware XTM v11.1 resolves a cross site scripting vulnerability found in the web server used with the authentication applet. [40332]

  • Fireware XTM v11.1 resolves a cross site scripting vulnerability found in the WatchGuard servers’ Apache HTTP server implementation. [40581]

  • The lighttpd version used by Fireware XTM has been upgraded to v1.4.22 to resolve several reported vulnerabilities. [38808]

  • The ISC DHCP server version has been upgraded to v4.1.0p1 to resolve several reported vulnerabilities. [40032]

  • HostWatch now shows VLAN traffic. [40401]

  • You can now right-click in Firebox System Manager > Traffic Monitor to add an IP address to the blocked sites list. [40488]

  • ServiceWatch now correctly displays bandwidth for auto-generated BOVPN policies created by the WatchGuard Management Server. [40364]

Authentication

  • The Authentication redirect feature now works when you use a wireless guest network on the Firebox X Edge e-Series. [40029]

  • This release resolves an issue that causes Active Directory authentication to fail with the following log message: user=”test1″ domain=TESTQAWIN2K30. [40786]

Proxies

  • You can now enable notification for Application Blocker. [40422]

  • Application Blocker has been enhanced to add support for Winny, a popular peer to peer application used in Japan. [35027]

  • You can now unlock a file with an “&” in the file name with the unlock.exe utility. [40718]

  • This release resolves several reported issues in which certain web applications did not work through the HTTP Proxy. [40293] [38121] [40392]

  • This release resolves an issue that caused FTP proxy traffic to stop after a multi-WAN failover. [37965]

Subscription Services

  • Subscription services now update when you use an internal HTTP proxy server. [40517]

  • WebBlocker override now works on Firebox X e-Series devices configured in Bridge Mode. [39283]

  • The Quarantine Server client now accepts firstname.lastname@domain.com email format. [39743]

Networking

  • You can now use either Policy Manager or the Web UI to add multicast addresses in a policy. [39947, 39948]

  • If you enable a network interface and change the Interface Name (Alias) at the same time you enable the interface, the interface now becomes active without the need for a reboot.[39815]

  • When you use multi-WAN, DNS servers with static IP addresses on WAN 1 are now used even when other external interfaces use DNS servers from an ISP through PPPoE or DHCP. [40322]

  • DHCP relay through a branch office VPN tunnel now works. [40844]

  • You can now change the MTU of an external interface configured with PPPoE. [40705]

  • The DHCP server now works when there are multiple VLANs in the configuration. [40556]

  • Server Load Balancing now works when the internal server IP addresses are on different subnets. [41041]

  • We have made enhancements to the Server Load Balancing server status detection mechanism. [40300] [40519]

  • The Server Load Balancing Stickiness function has been improved to maintain a sticky connection state until the idle timeout is reached. [40297]

  • Static MAC address binding now works when your device is configured in Bridge Mode. [40665]

  • This release resolves an issue that prevented some Windows computers from getting an IP address via DHCP when your device is configured in Drop-In Mode. [40184]

  • The Blocked Ports and Blocked Sites features now apply only to traffic on an external interface. [39918]

Multi-WAN

  • Several multi-WAN issues related to PPPoE and branch office and Mobile VPN have been resolved. [40007]

  • Multi-WAN now works when the source IP address for incoming traffic is on the same network subnet as one of the external interfaces of the Firebox. [41026]

  • This release resolves an issue that caused the external interfaces to become inactive when you used multi-WAN configured in Round-robin mode. [40357]

FireCluster

  • Firebox devices with a model upgrade in the feature key can now join a FireCluster. [39370]

Branch Office VPN

  • The choice of Any has been removed from the Tunnel Route Settings Local and Remote drop-down menu. The Web UI now shows “any (0.0.0.0/0)”. [40409]

  • This release resolves an issue that caused the IKED process to crash and all IPSec tunnels to fail. [40442]

Mobile VPN

  • The Windows SSL VPN client has been updated to support Windows 7 and Windows 64-bit operating systems. [39841]

  • This release resolves an issue that caused SSL VPN to fail to connect after an upgrade from v10.2.x to v11.0.x. When this problem occurred, the SSL VPN client logs showed: sslvpn State: initialization of prerequisites Debug. [40408]

  • This release resolves several reported vulnerabilities in the SSL VPN client for Mac. [40292]

  • Mobile VPN with PPTP and SSL now continue to work when the LiveSecurity subscription is expired in your Firebox feature key. [41045]

  • When you disconnect the Mobile VPN with SSL client from one Firebox and then connect to a different Firebox, the SSL VPN profile is now updated to show the new connection. [41052]

  • The Mobile VPN with IPSec v11.1 client supports Windows 7 (32-bit and 64-bit) and contains additional bug fixes.

Web UI

  • You can now export your device configuration with the Web UI. [35234]

  • The Web UI now prevents the use of custom SSL VPN ports that conflict with ports used by the Firebox. [39382]

Policy Manager

  • The Firebox no longer becomes unresponsive if you use more than 28 characters in a proxy policy name. [40679]

  • The alias “Firebox” is now treated the same as other aliases the Firebox determines policy precedence. [38891]

Management Server

  • When a Firebox is in Full Management Mode and you clear the Enable TCP Syn Checking check box, TCP Syn Checking is now correctly disabled. [40853]

  • When a Firebox is under centralized management, an update from the WatchGuard Management Server no longer overwrites any blocked sites configured manually on the Firebox. [40312]

  • You can now right-click on a device and add that device to a folder. [36077]

  • The ability to schedule a reboot time is now available from the Management Server. [38230]

  • You can now perform a mass update of managed devices to force all selected appliances to check for a configuration update. [36958]

  • The Management Server now sorts the IPSec-action-list and abs-ipsec-action-list for tunnels created by the Management Server. The IPSec actions for Manual BOVPN tunnels are left in the order sorted by the user. Manual tunnels are always placed at the top of the list, followed by the sorted list of the tunnels created by the Management Server.

  • For each firewall policy template in use, there is now a single firewall policy created in the appliance configuration. As an example, if you have three tunnels (to different endpoints) that all use the same firewall policy template, there is a single firewall policy with the attributes set in the template. If there are two firewall policy templates in use, then two firewall policies are created. [38877]

Report Server

  • If you use an IIS server to serve published reports, you no longer get an error about missing files. [39319]

Log Server

  • The performance of the LogViewer Search function has been improved in v11.1. To facilitate the performance improvements, a log database migration will occur when you upgrade from v11.0.x to v11.1. During the migration, all log messages generated for a particular device are not visible until the migration is finished. [38833]

Certificates

  • You can now import a CRL in DER format into Firebox System Manager. [36643]

  • This release resolves a memory leak that occurred when you used 3rd-party certificates on the Firebox and kept WatchGuard System Manager or Firebox System Manager connected. [41008]

  • WatchGuard System Manager and Firebox System Manager no longer display the certificates status as valid even if a certificate is invalid. [40378]

Achtung bei Migration auf Fireware XTM: Routing Table – Abarbeitung ändert sich

1 Comment

Momentan habe ich wenig Zeit für meinen Blog, weil jeden Tag neue Support-Anforderungen bei mir eingehen. Admins migrieren ihre WatchGuard Firebox mit bestem Wissen und Gewissen auf Fireware XTM (Version 11) – und erleiden bisweilen Schiffbruch. In den allermeisten Fällen lassen sich die Probleme darauf zurückführen, dass bei Fireware XTM (Version 11) die interne Routing Table der Firebox in einer anderen Reihenfolge abgearbeitet wird als bei der bisherigen Fireware 10.2.x.

Generell gilt bei XTM: VPN hat Vorrang!

Welche Probleme können daraus entstehen und welche Lösungsansätze gibt es:

  • 1. Mobile User VPN. Während noch bei der Version WFS 7.x empfohlen wurde, den IP-Pool für die Einwahl der mobilen User INNERHALB des lokalen LAN-Subnetzes zu definieren (Beispiel: LAN = 192.168.0.0/24, mobile User (egal ob PPTP oder IPSec) bekommen 192.168.0.200 bis 220 zugewiesen), ist dies bei Fireware XTM (Version 11) grundsätzlich ein Problem und führt zu gravierendem Fehlverhalten.

    Verwenden Sie grundsätzlich für die Einwahl von mobilen Usern IP-Bereiche, die in dieser Form an keiner anderen Stelle Ihrer (verteilten) IP-Infrastruktur verwendet werden. Ich persönlich verwende gerne für PPTP den Bereich 172.31.254.1 bis 50, für IPSec 172.31.255.1 bis x (je nach Lizenz) und für SSL-VPN 172.31.253.0/24. Diese Bereiche werden in aller Regel noch nicht für andere Zwecke verwendet – und haben eben den Vorteil, dass die WatchGuard Firebox zu diesen Bereichen ein sauberes Routing fahren kann.

  • 2. Network > Routes. Das Problem hier lässt sich anhand von folgendem Support Fall verdeutlichen: als eth1 (=Trusted) war bei einem Kunden definiert: 192.168.0.1/30, d.h. außer der Firebox gibt es in diesem Subnetz nur noch genau einen weiteren Host, 192.168.0.2. Dies ist ein Standleitungs-Router, der eine Leitung zu einem 10-er IP-Netz am Hauptstandort des Unternehmens bedient, an dem sich auch die AD-Domänencontroller des Unternehmens befinden, über die u.a. auch die Einwahl der mobilen User gegenüber Active Directory authentifiziert wurde (Eintrag unter Setup > Authentication > Authentication Servers > Active Directory). Dummerweise gab es in dieser Konfiguration auch noch einen BOVPN-Tunnel (sprich eine feste Außenstelle), der auf der Gegenseite das IP-Netz 192.168.0.0/24 bedient hat. Während unter der Software-Version Fireware 10.2.x das auf eth1 definierte lokale Netzwerk 192.168.0.0/30 Vorrang hatte und daher die DCs in dem 10-er Netz per Routing erreichbar waren, verhält sich die WatchGuard Firebox unter Fireware XTM (Version 11) nun anders und schickt den Traffic zu dem Standleitungs-Router 192.168.0.2 nun nicht mehr zum lokalen Interface eth1 raus – sondern packt ihn in den Tunnel in die Außenstelle x ein, wo er im Nirwana landet… Problematik klar? In diesem Fall am einfachsten die Konfiguration von eth1 und die IP-Adresse und das Routing des/zum Standleitungs-Router so abändern, dass das verwendete IP-Subnetz an keiner anderen Stelle der Unternehmens-IP-Infrastruktur verwendet wird…

  • 3. Problematik: vermaschte IP-Netze. Unter einem “vermaschten IP-Netz” verstehe ich hier ein verteiltes Netzwerk mit mehreren Standorten, die auf TCP/IP-Basis miteinander kommunizieren können, wobei das Routing jedoch nicht direkt von Außenstelle zu Außenstelle geführt wird, sondern über einen gemeinsamen, zentralen Punkt (i.d.R. ein Rechenzentrum). Auch ich habe in der Vergangenheit Netze gebaut, die in einer Außenstelle z.B. ein IP-Netz à la 10.0.23.0/24 verwendet haben – und einen BOVPN-Tunnel zu 10.0.0.0/8 hinter einem zentralen Gateway angesteuert haben. Dort befand sich eine WatchGuard Firebox X Core oder X Peak, die den Traffic angenommen hat – und auch tatsächlich wieder korrekt in die ebenfalls dort terminierten BOVPN-Tunnel zu den anderen Außenstellen eingepackt hat. Damit ließen sich auch schon in der Vergangenheit zentralisierte VoIP-Lösungen (z.B. Asterisk, Siemens HiPath, Avaya) abbilden. Ein Problem entsteht unter Fireware XTM insbesondere dann, wenn auch das zentrale Netzwerk in einem IP-Subnetz des o.g. vermaschten Netzwerks betrieben wird. Die zentralen Server sind dann aus den Außenstellen heraus nicht mehr korrekt erreichbar. Trifft dieses Szenario auf Sie zu, sprechen Sie mich bitte direkt an, um eine Lösung gemeinsam zu erarbeiten.

  • 4. Allgemein gilt: sofern Ihre IP-Infrastruktur *KLAR* definiert ist und es zwischen den verwendeten IP-Bereichen keine Konflikte/Überschneidungen gibt, wird ein Update auf die aktuelle Version WSM 11.x und Fireware XTM v11.x relativ einfach und überschaubar über die Runden gehen.

HA Cluster: “Peer Status is in-transition”

Comment

Beim Speichern einer neuen Konfiguration auf einen HA Cluster kommt es bisweilen zu dem Zustand Peer Status is in-transition anstelle des normalen “Peer Status is standby”. Zu diesem Verhalten kann es kommen, wenn während des Speicherns gerade mobile User über PPTP-VPN eingewählt sind.

[30.01.2009]: Laut Release Notes soll dies nun mit der Fireware 10.2.7 behoben sein.