Release date: 2001-04-20 [ISO]

Version 6.01 is mainly a bug fix / maintenance release. There are, however, a few changes and improvements; the most visible ones are in the FireWall Manager, and substantial performance improvements in the built-in network card drivers.

This document outlines bug fixes as well as improvements for each component.

New files installed by v6.01
How to upgrade a v6.00 firewall to v6.01
How to upgrade a v5.xx firewall to v6.01
FireWall Manager	[Changes]	[Bug Fixes]
FireWall Core	[Changes]	[Bug Fixes]	[Known Bugs / Problems]
VPN Core		[Bug Fixes]	[Known Bugs / Problems]

For future reference: This document is stored in the "Docs" sub-folder of your EnterNet FireWall install folder.

• Cores/fwc_601.exe
  This is the v6.01 standard firewall core. Upload it to your existing (standard) firewall, or create new boot media with it.
  Note: VPN firewalls should, as always, use the VPN core file, below.

• Cores/fwc_601v.exe
  This is the v6.01 VPN firewall core. Upload it to your existing (VPN) firewall, or create new boot media with it.
  Note: This file is not installed by the standard installation package, as only licensed users have access to it. Rather, it is available as a separate installation package (typically an EnterNet Upgrader package).

• Docs/Changes-6.00-to-6.01.htm
  This document.

• FWMgr6.exe
  This is the v6.01 FireWall Manager; it will overwrite the previously installed version 6 firewall manager. Version 5 firewall managers (if installed) will not be overwritten, as they are named "FWMgr.exe".

• The "FireWall" menu in the "FireWall List" view has changed
  The "Advanced" submenu has been split into three separate submenus:
  • Communication: Upload/download configuration, Upload core, Re-read configuration, Restart firewall, Change firewall keys.
    The "Re-read configuration" and "Restart firewall" commands are new. They perform a configuration re-read and core restart, respectively, and then initiate bi-directional communication verification. Hence, they may be used to activate previously uploaded (but not activated) configurations.
  • Database: Edit config file, New firewall, Delete firewall, Export firewall entry.
  • Boot Media: Create boot media, Save to boot media, Load keys from boot media.

• Load and save profiles in the statistics view
  Profiles - sets of graphs to display - may now be saved per firewall, via File -> Load/Save Profile. These profiles are saved in the management database rather than in the local registry. Hence, they may be used and defined by any FireWall Manager accessing the same management database.

• Statistics graphs can now be hidden / double-sized
  The graphs in the statistics view are now automatically drawn as double-sized when selected in the legend (list view). They may also be hidden and double-sized through the context (right mouse click) menu.

• Statistics graphs colors may be adjusted
  The colors of the statistics graphs may be adjusted via View -> Select Colors. These settings are saved locally rather than in the management database.

• Shortened path for uploading and activating configurations
  Rather than displaying separate dialogs, asking whether or not to upload and activate an edited configuration, this has been combined to one single dialog containing check boxes.

• Copying and pasting cells in configuration
  Previously, it was only possible to copy and paste cells containing plain text. Now, this is also possible with cells that are edited through extended dialogs, such as "Pipes", "Proto/Params", etc.

• Attaching to log receivers inside subdirectories
  (This was fixed in FWMgr 6.00.01, but is included here for completeness)
  Issue: FireWall Manager 6.00.00 was unable to connect to log receivers residing in non-root directories. By "non-root" directories, we mean anything not at the root directory of a drive (e.g. "c:\") or of a share (e.g. \\server\share).
  Fix: This was fixed in FireWall Manager v6.00.01.
  

• Too many statistics values caused grayed (disabled) Plot menu items
  Issue: The plot menu of the statistics view has a hard-coded limit on the number of possible graphs. This limit was set too low for configurations with many pipes; each pipe results in approximately 60 graph values to select from.
  Result: Plot menu items at the bottom of the list became grayed (disabled).
  Fix: The previous total limit was 1000 graphs.
  This is now expanded to 4000 graphs.
  

• 3com 3c905 built-in driver performance boost
  The 3com 3c905 built-in drivers of EnterNet FireWall are now about 70% more efficient than ever before. This means that:
  • A packet stream that previously caused a 60% CPU load will now cause a mere 35% CPU load
  • If a packet stream of 75000 packets per second previously caused 100% CPU load, your system will now be capable of passing more than 125000 packets per second before reaching 100% CPU load

  This improvement is likely more noticeable with short packets. The same 70% performance boost does exist with large packets, but, for EnterNet FireWall installations, the limiting factor for large packet streams is typically the PCI bus / host bridge performance of your hardware, or the number of interfaces, rather than sheer CPU power.

• DEC/Intel Tulip built-in driver performance boost
  The DEC/Intel Tulip chipset built-in drivers of EnterNet FireWall are now about 20% more efficient than before. For small packet streams, they are 50% more efficient. For large packet streams, they are 10% more efficient. The 20% figure represents a typical traffic mix of 50% small packets, 50% large packets.

• Syslog: Connection field names have changed
  Information regarding statefully tracked connections was previously logged as "srcip", "srcport", etc. This was conflicting with packet dump field names, in log messages containing both connection information and packet dumps.
  The following names have changed:
  
  • recvif -> connrecvif
  • destif -> conndestif
  • srcip -> connsrcip
  • destip -> conndestip
  • ipproto -> connipproto
  • srcport -> connsrcport
  • destport -> conndestport
  • srcid -> connsrcid (used in pings only)
  • destid -> conndestid
  These changes do not affect the EnterNet FireWall Logger log format.

• Could not attach more than 10 interfaces
  Issue: In order to support more than 10 interfaces, additional packet buffers need to be allocated during configuration. These buffers were allocated too late, which had the unfortunate effect that no more than ten interfaces could be attached; each interface needs sixteen packet buffers for its receive handlers.
  Affects: FireWall Core v6.00.0x.
  Results: If more than 10 interfaces were attached, the firewall would crash and restart as soon as any interface above the first 10 interfaces received a packet. The first 10 interfaces would function normally.
  Fix: Additional buffers are now allocated (according to the HighBuffers setting) as soon as interface number nine is being attached. Alerts have also been added to the attach functions so that a visible error will be produced if the core runs out of buffers while attaching interfaces.

• 3com 3c905 driver reconfigure/restart behavior improved
  Issue: The built-in 3com 3c905 drivers are having problems during configuration re-reads or core restarts; on some systems, one or more NICs may stop receiving or sending data, especially if the reconfigure/restart occured under high load. This has now been improved, but not yet completely resolved. There are still a few systems with reconfigure/restart problems.
  Affects: All v6.00 cores using the 3c905 built-in drivers. Improved in v6.01.
  Other NIC drivers are not affected, nor the ODI version of the 3c90x driver: "3c90x.com".
  Slow systems, or systems under heavy load, are more likely to be affected than fast systems, or ones with low traffic loads.
  Note: The problem only ever occurs on reconfig/restart, never on power-up.

• DEC/Intel Tulip driver receiver lock problem fixed
  Issue: During high loads (99-100% CPU load), the firewall may run out of free buffers. This also affects the receive rings of the network cards, who also may run out of buffers. The receive rings should be re-filled when there are new buffers available, but this was not working properly.
  Result: If a network card ran out of buffers, it would not be able to receive packets until a reconfigure/restart command was issued. The ifstat console command would show a steadily increasing Packets missed counter.
  Affects: All v6.00 cores using the tulip built-in drivers. Fixed in v6.01.

• SAT/NAT of UDP packets with zero (don't care) checksum
  Issue: UDP packets may be transmitted with a checksum of zero, meaning "I don't care if the data gets scrambled during transmission". The address translation code needs to adjust UDP and TCP checksums when altering the address and port fields of the packet. However, it did not take the zero-checksum into consideration, which resulted in the checksum becoming something other than zero; usually wrong.
  Affects: All cores v5.10 to v5.12. All cores v6.00. Fixed in v5.13 and v6.01.
  EnterNet is currently only aware of two applications utilizing "don't care" UDP checksums: "echo" services (port 7) on some operating systems, and one or more brands of load balancing DNS servers. We have not determined exactly which ones.
  Again: non-address translated connections to systems utilizing zero UDP checksums were not affected.
  Result: The visible result was being unable to query DNS data for zones with such load balancers if address translation of outbound DNS queries was performed, and being unable to connect to echo services on some systems.
  Fix: The address translator will now refrain from adjusting zero UDP checksums.

• Duplicate fragment data comparison wasn't working
  Issue: When the firewall receives a duplicate of a fragment that it already has in queue, it should compare its data according to the DuplicateFragData check. This was not working.
  Affects: All cores v5.10 to v5.12. All cores v6.00.
  Fixed in v5.13 and v6.01.
  Results: Fortunately, there are no known attacks involving changing duplicate fragment data; this check is only an added level of paranoia.

• Static/published ARP entries disappearing on Y2K-incompatible systems
  Issue: Computers with Y2K-incompatible BIOSes may cause the firewall to believe that the current date is well beyond year 2036, which was the timeout value for static/published ARP entries.
  Result: Static/published ARP entries disappeared as soon as the configuration was read.
  Affects: All cores up to v5.12 and v6.00. Fixed in v5.13 and v6.01.
  Affected any system reporting its date as being beyond year 2036, either due to Y2K-incompatibility or due to faulty clock settings.
  Fix: ARP entry life time is now relative to the number of seconds of uptime, meaning that a firewall can now run 136 years without timing out its static/published ARP entries, regardless of what the system time is.
  

• Raptor 6.5 SYN flood protection (RST cookies)
  The SYN flood protection in Raptor 6.5 uses RST cookies, which EnterNet FireWall does not support. We are currently unsure as to whether we should support this or not, as RST cookies is a very weak form of SYN flood protection. The ideal solution would be for Symantec / Axent to develop a better SYN flood protection and stop using RST cookies. (More information on RST cookies)

• 3com 3c905 driver sometimes hangs on reconfigure/restart
  Although this problem has been mitigated with the v6.01 release, it still exists on a few systems. We will address this issue, but felt that releasing v6.01 in its current state was appropriate, as it does resolve the problem on most of the systems exhibiting this behavior.

• Spurious packets passed to VPN when using ODI drivers
  Issue: When using ODI drivers, packets that were supposed to be transmitted as plaintext would sometimes erroneously be passed to the IPsec code, which, in turn, would drop them.
  Result: This problem would be seen as "packet loss", and IPSEC category log entries saying "cannot get policy for", followed by an IP address unrelated to your VPN connections.
  Affects: VPN cores v5.10 to v5.12. VPN core v6.00. Fixed in v5.13 and v6.01.
  Again, this problem only occured when using ODI drivers, not built-in drivers.
  Note: There is not a reverse to this problem. Packets destined for VPN connections were never being spuriously passed in plain text.

• IKE phase-1 ID being set to "0.0.0.0" in responses
  Issue: During IKE phase-1 negotiations where the firewall is acting as the responder, the ID was being set to "0.0.0.0", rather than the IP address of the firewall.
  This caused problems with some (newer) VPN software, which require the ID to be set correctly.
  Result: The visible result is the remote VPN software refusing to (re-)establish an IPsec connection; often with an error message along the lines of "unknown ID".
  Fix: The firewall now sets the ID to the IP address of the sending interface.
  Affects: VPN cores v5.10 to v5.12. VPN core v6.00. Fixed in v5.13 and v6.01.
  Again, this problem only occured when using ODI drivers, not built-in drivers.

• Display bug in the "vpnstats" console command
  Issue: IP networks were being incorrectly displayed in the "vpnstats" console command.
  Result: For example, the network "10.4.5.0/24" would be displayed as "10.4.5.0 - 10.4.5.24", rather than "10.4.5.0 - 10.4.5.255".
  Affects: VPN core v6.00. Fixed in v6.01.
  

• Cannot configure ESP without an HMAC
  The firewall will not accept a configuration of an ESP proposal that is not using an HMAC (authentication code). We regard this as a low-priority problem, as using ESP without authentication is very undesirable and unlikely to be required by anyone.

The result on your end
EnterNet FireWall refuses to send RSTs in response to these bogus ACKs. Rather, it generates a log entry and drops the packet. The result is that users behind an EnterNet FireWall cannot connect to machines behind a Raptor firewall with SYN flood protection enabled.

Why EnterNet does not want to support RST cookies
There are many others that have discarded RST cookies as a viable approach to SYN flood protection. For example, the Linux kernel previously implemented an optional SYN flood protection via RST cookies. The open-source community saw it fit to remove the RST cookie scheme in recent kernels, for several reasons:

• It doesn't work very well with a lot of firewalls
  
• It still consumes resources on the server end, which is exactly what a SYN flood is designed to do.
• It's a fairly weak form of SYN flood protection; there are other approaches that are by far more preferable.
• It does not prevent you from actually SYN flooding the server / firewall. It only (supposedly) prevents you from doing so from a spoofed (fake) IP address.
• If you are spoofing an existing host, that host will happily respond to the bogus ACK with a RST, so it is always entirely possible to SYN flood someone spoofing the IP address of another (existing) host.

Sidenote on the Raptor RST cookies
The Raptor RST cookies are even weaker than the designers of the RST cookie scheme intended for them to be. The "secret" in the bogus ACKs generated by Raptor firewalls is simply the sequence number of the original SYN (that the attacker sends), plus 1 000 000.
Hence, it is entirely possible to send a SYN from a spoofed source IP to a Raptor firewall, and immediately afterwards send a RST with the sequence number of the original SYN, plus 1 000 000.

Conclusion
Given the ineffectiveness of the RST cookie scheme, EnterNet would much rather see that Symantec / Axent redesign their SYN flood protection than having to support it in EnterNet FireWall. Supporting it generates unnecessary complexity, and quite possibly opens up avenues of exploitation that we are quite sure that our users could do without.

Workarounds
There are no workarounds on your end. The only workaround is to turn off the RST cookies in the firewall / server causing the problems.
If you are having problems accessing a site employing a RST cookie SYN flood protection scheme, we recommend that you contact the site admin and ask him/her to turn the "protection" off; it isn't doing them any good. Also, be reassured, you are far from the only one having problems accessing that site, since this protection scheme causes problems with several other firewalling solutions.

How do I know if RST cookies are causing my problems?
If you are seeing DROP log entries with a rule of "LogStateViolations", concering a connection in "SYN_SENT" state, and the dropped packet is TCP with the ACK flag set, you can be fairly certain that you're witnessing the result of the RST cookie protection scheme.