Tag Archives: “Fire Box”

Watchguard XTM 1050, XTM 2050, XTM 2 Series, XTM 3 Series, XTM 5 Series, XTM 8 Series – Fireware XTM OS 11.6.1 – Build # 346666

Watchguard XTM 1050, XTM 2050, XTM 2 Series, XTM 3 Series, XTM 5 Series, XTM 8 Series – Fireware XTM OS 11.6.1 – Build # 346666

11.6.1 – Build # 346666 Provides some new features and resolves the following issues:

• This release introduces support for the new high-performance XTM 5 Series models 515, 525, 535, and 545

• Provides an update to our localized user interfaces and documentation

• An XTM device configured in bridge mode can now pass VLAN traffic between 802.1Q switches or bridges

• FireCluster support for XTM 25, 26, and 33 wired models

• Several issues have been resolved in this release that caused XTM devices to crash when configured to use Application Control or IPS [66937, 65426, 65636, 67312, 66135, 67159, 67399, 67310]

• An issue was resolved that caused some XTM device processes to crash when running Mu Dynamics default published vulnerability test [66490]

• An issue was resolved that caused a kernel crash and device reboot [67329]

• The XTM 2 Series device can now handle a large file transfer without interface instability [67367]

• A problem that caused incorrect data to display on the XTM 5 Series LCD screen has been resolved [67197]

• Policy Manager now displays the correct VLAN limits for XTM 5 Series models 505, 510, 520, and 530 with a standard Fireware XTM feature key (not Pro) [67780]

• You can now successfully configure and apply Traffic Management actions for XTM 2 and 3 Series devices from the Web UI [67221, 66645]

• Firebox X Edge e-Series devices can now be successfully managed with templates [67658]

• The notification message sent when a local Log or Report database is down now correctly shows the host IP address instead of “???” [41731]

• The Log Server can now handle backup files greater than 2GB in size without generating an error message: “Error (8199), Exception during backup of oldest log data: File is not a zip file” exception” [66811]

• The DHCP lease activity report now works correctly [66062]

• Log Collector now handles XTM device log data that spans multiple SSL/TLS records without crashing [66347]

• A problem has been resolved that caused poor performance on XTM 2 Series models 25 and 26 because of an incorrect memory allocation for security subscription signatures [67240]

• A deny message is now correctly sent to the web browser in most cases when Application Control blocks content in the Web/Web 2.0 category [66201]

• The WebBlocker automatic database update time is no longer off by one hour when daylight savings time is in effect on the host server’s timezone [67551]

• If you use PPPoE or DHCP for an external interface on an XTM device configured to use multi-WAN, the XTM device no longer loses the default routes for external interfaces after the external interface reconnects [67424, 67520]

• A problem has been resolved that caused a static route to fail after an external interface configured to use PPPoE is disconnected, then reconnected [67520]

• Tagged VLAN traffic is now correctly recognized when an XTM device is configured in Bridge mode [64355]

• The CLl command “restore factory default all” now successfully restores a device to its factory default settings [66240]

• An issue has been resolved that caused Policy Manager to incorrectly display an interface IP address as 0.0.0.0/24 when you viewed a FireCluster configuration for a cluster in drop-in mode [63551]

• The Mobile VPN with SSL process no longer crashes during a FireCluster failover [66118]

You can download 11.6.1 – Build # 346666 from the Watchguard website

Watchguard XTM 2 Series, XTM 3 Series, XTM 5 Series, XTM 8 Series – Fireware XTM OS 11.5.1 – CSP4 Build # 335367

Watchguard XTM 2 Series, XTM 3 Series, XTM 5 Series, XTM 8 Series – Fireware XTM OS 11.5.1 – CSP4 Build # 335367

11.5.1 – CSP4 Build # 335367 Resolves the following issues:

BUG64669: Resolved a Firebox crash and reboot when using FireCluster.

BUG63793: Improved proxy debug logging when using FireCluster.

BUG63574: Proxy connections fail with logs showing: “failed to create new traffic spec” and “insert_tspec:XX index inuse?

BUG65026: Iked stack trace eip=0x080c4013 caused by Mobile VPN with IPSec connection.

BUG63860: snmpd memory leak

You can request 11.5.1 – CSP4 Build # 335367 from Watchguard Support by logging a support case online, they should then be able to provide an ftp download link and appropriate credentials.

Please note that Watchguard CSP releases are cumulative so you should only need to apply the latest to ensure that you also have any previous fixes.

Watchguard – SSL VPN clients cannot resolve internal host names despite DNS servers being configured for the connection

You may find that when you configure your Watchguard XTM Firewall to accept SSL VPN connections that clients can connect to

the VPN and ping IP addresses of internal resources, however you cannot resolve internal hosts even via FQDN using DNS.  You

may also find that when you run NSLOOKUP on the SSL VPN connected client that the  result is your Internet Service Providers

DNS servers rather than the DNS servers assigned via the VPN connection.

 

To resolve the issue you can change your SSL VPN configuration from a “Routed VPN” to a “Bridge VPN”, the routed VPN uses a

virtual IP address pool (192.168.113.0/24) which does not match your internal IP range or the address range of the internal

DNS Servers.  When a Windows client connects to the “Routed VPN” it appears that due to the DNS server mismatch they are not

utilised by the client.

 

When you configure the VPN in “Bridge VPN” mode you can work around this issue, the Bridge VPN configuration allows you to

exclude some addresses from your Windows DHCP Server Pool and add the into them “Start” and “End” IP addresses on your

Watchguard SSL VPN Configuration Page. The Watchguard will now become responsible for assigning these internal IPs to VPN

clients as they connect rather than the Windows DHCP Server.

 

You should now find that when your SSL VPN clients connect that they are assigned an IP address and DNS server that are all

within the existing internal IP range of your network.  An NSLOOKUP should now return your internal DNS server address and

you should be able to ping hostnames and FQDNs that reside within your internal network.

 

Examples:

ping windowsserver

ping windowsserver.exampledomain.local

 

Please remember that the only down side with this configuration is that a “Bridge VPN” bridges to the “Trusted” interface,

this means that the client computer can access any internal resources that they have permissions for by default. A “Routed

VPN” allows you to offer traffic to Optional/secondary networks and gives you more control by letting you lock down access

using “Specify allowed resources”.