Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

3Com Embeds Firewall in PC NICs: Page 2 of 3

To allow outbound HTTP, for example, I created a rule that permitted TCP outbound from the EFW address from source ports 1,024 through 65,535 to any destination IP address on Port 80. I defined a second rule that allowed inbound TCP from source Port 80 to the EFW IP address and any port 1,025 through 65,535. You can reuse your rule sets as needed to define common access policies. In addition, 3Com provides several predefined policies. Once you create or modify the policy, it is pushed out immediately to all connected EFWs in the device set.

Making Connections

Good
• End users cannot disable the firewall policy.
• Effective group management for easy deployment.
• Works when remote EFWs are behind NAPT routers.
Bad
• The PC Card can be removed--and the policy with it.
• You must create inbound and outbound rules.
• Support limited to the Windows platform.

The Policy Server and the EFWs communicate over UDP when the EFW checks in with the Policy Server or sends events. There is a problem if the EFW is behind an NAPT router. Because UDP is connectionless, many network devices, including NAPT devices, determine that the connection is no longer active if there is no UDP traffic for a designated period of time so the NAPT association is removed. The connection to the Policy Server won't be re-established until the EFW initiates it. Unfortunately, if a policy update needs to be served but there is no established connection between the EFW and the Policy Server, the EFW policy won't be updated until the connection is re-established.

3Com offers two solutions to the NAPT problem. The Policy Server will wait for the EFW to check in periodically with its heartbeat. When this happens, the Policy Server will push the new policy to the EFW using the established UDP connection. Bear in mind, though, that intervals between heartbeats can be very long--hours, days or even a week. Better yet, you can set the EFW heartbeat for device sets that represent roaming users to update every two minutes. By using a relatively fast heartbeat, chances of the UDP connection timing out are slim, and the Policy Server will be able to reach the EFW whenever a policy changes.

Regardless of the method used, the EFW always attempts to contact the Policy Server on boot-up. If it is successful, it will get the updated policy. In the event the EFW can't contact the Policy Server, it can be configured to implement a fallback policy, such as allowing or blocking all traffic or implementing the last known good policy.