How does the ASA push the rules to the client?
One the rules are defined and a connection is being established, the rules are passed to the client via a CSTP handshake during the setup. The agent takes a snapshot of the existing firewall rules and applies the received rules to the native firewall available on the operating system. As of now, this handshake isn't tracked via debugs, any errors are only logged on the client.
What platforms are currently supported?
- Windows XP SP2
- Windows Vista
- Windows 7
- MAC OS X 10.5
- MAC OS X 10.6
Linux, Windows Mobile and other new mobile platforms are not yet supported.
ENH # http://cdets.cisco.com/apps/dumpcr?&content=summary&format=html&identifier=CSCtx55751CSCtx55751 has been filed to add support to linux clients
Where are the rules applied?
1. Windows
The rules obtained from ASA will be applied to the Windows Firewall present on the supported Operating Systems. For older operating systems on which AnyConnect gets installed (Windows 2000 and XP pre-SP2), the firewall feature will softly fail, logging an error message that the OS is not supported for this feature. Rules are applied to all the windows profiles.
2. MAC
The rules will be applied to ipfw, the legacy firewall present in MAC. The native application firewall present on OSX 10.5 and OSX 10.6 do not have any APIs that we can utilize. However, its presence does not prevent us from configuring ipfw. So, there is no necessity for us to disable the application firewall.
What is the significance of the source and destination port numbers in the access list?
The primarily role of the port numbers is ofcourse to identify what service to permit or allow for a certain protocol. However, the ports numbers, and how they are applied also play another very significant role. Depending on whether the source or/and the destination port is defined in the access-list, the direction in which this rule will be applied to firewall will be determined. To enumerate:
- If source port and destination port are specific number, the rule applies to both inbound and outbound traffic.
- If source port and destination port are specified as a range or ‘All’ (value of 0), the rule applies to both inbound and outbound traffic.
- If the source port is a specific number and the destination port is a range or ‘All’, the rule applies to inbound traffic.
- If the source port is a range or ‘All’ and the destination port is a specific number, the rule applies to only outbound traffic.
The ASDM does a poor job of explaining this to users. Bug # http://cdets.cisco.com/apps/dumpcr?&content=summary&format=html&identifier=CSCtg79827CSCtg79827 was filed to enhance this. To configured a source port in the ASDM click on the "more" options when adding an ACE. The thing you need to keep in mind while configuring or modifying the acecss-list from the ASDM is that the way ASDM displays the ACLs it won't display the source port, i.e. if you have the following access-list:
access-list acl_client_fw_test extended deny icmp any any
access-list acl_client_fw_test extended deny tcp any eq 3389 any
access-list acl_client_fw_test extended deny tcp any eq 3340 any
access-list acl_client_fw_test extended permit tcp any any eq 3340
In the ASDM, this will look like:
This doesn't mean the access-list is wrong, it just means it's displayed incorrectly. This should have been addressed by bug # http://cdetsweb-prd.cisco.com/apps/dumpcr?identifier=CSCse02836&content=summary&format=htmlCSCse02836, but ever since 2k6 no one really got around to it, so if you're in this area feel free to attach this bug to your case.
However, there are some caveates:
http://cdets.cisco.com/apps/dumpcr?&content=summary&format=html&identifier=CSCtg45671CSCtg45671: on XP machines due to limitations of the OS, the client firewall policy on computers running Windows XP is enforced for inbound traffic only. Outbound rules and bidirectional rules are ignored.
CSCtx27707: on win 7 if you define an access-list denying a particular source port then all inbound traffic to that port should be blocked. However, currently what happens when you define such an entry is all outbound/inbound internet access gets blocked. I am nost sure if this applies to XP machines as well, however developer viskrish is working on both issues.
What is the difference between Public and Private rules?
The value public/private indicates which interfaces to apply the rules on. Public rules are applied on all interfaces on that client machine. Private rules, on the other hand, are applied only to the virtual adapter so for traffic not being encrypted these rules would have no effect.
When should the public rules not have any effect even if they are pushed down?
The administrator has to explicitly configure split tunneling of some kind for the public firewall rules to take effect. Enabling the firewall feature does not automatically imply opening local LAN. If the agent detects there is no split tunneling configured, the public firewall rules will not be applied and a configuration error will be logged. The connection will proceed. This has no effect on private rules, which will be applied regardless.
What happnes if the client is unable to apply all the rules?
Currently, if for some reason:
- applying a public deny firewall rule fails, the agent disables all split tunneling and logs the failure.
- applying a private rule fails, the error is logged but no further action is taken.
Enhancement request # http://cdetsweb-prd.cisco.com/apps/dumpcr?identifier=CSCtu00005&content=summary&format=htmlCSCtu00005 has been filed to change this behavior so that if the installation fails the adminsitrator has the option to prevent the connection completely.
What happens if the local Firewall service is stopped or disabled before Connection?
If the firewall service is stopped or disabled, AC wILLenable it and start the service before applying our rules. This is done only when there are firewall rules configured on the ASA. On a service shutdown or VPN disconnect, the original state of firewall SHOULD be restored.
However currently if the firewall policy was disabled before the connection, then on disconnect the client machine will lose complete internet access. This is documented in bug # http://cdetsweb-prd.cisco.com/apps/dumpcr?identifier=CSCts38500&content=summary&format=htmlCSCts38500 and should be fixed as of v3.0.5075. This begs the next question:
When should the fw rules continue to apply, even after disconnecting AC?
Sometimes even after disconnecting from the ASA, the rules continue to apply. This will usually occur if you have Always on enabled and and ApplyLastVPNLocalResourceRules setting implies that failure policy is “Closed”. This is by design. When the agent starts up, it reads the firewall rules that are obtained from ASA and keeps them in memory. On a service shutdown, they are written to the disk for possible offline usage. If on a service restart, the agent is not able to contact the ASA, the agent reads the stored rules and applies them to the native firewall, and deletes the stored copy. However with Always-on disabled or Always on enabled with Fail Open policy, this should not happen.
What happens if a third party software/root user disables the FW after the connection is complete?
Currently there is no easy way of securing the firewall rules that are created or lock down the firewall and disallow others from modifying the rules. On Windows, you can use AD GPOs to prevent adding more rules through the Windows Firewall User Interface and to disable deletion of our rules. However, the group policy can apply restrictions only on the basic firewall UI and not to changes made with Advanced Security UI found in Vista and Windows 7. Similarly on MAC, users with root privileges will always be able to modify the rules. So to get around this the client is designed to constantly poll the state of the FW and the rules, and if it notices any modifications, it logs an appropriate error, disables all split tunneling, and configures tunnel-all.
ENH # http://cdets.cisco.com/apps/dumpcr?&content=summary&format=html&identifier=CSCtx55897CSCtx55897 has been filed to add the ability to secure the rules pushed by the client.
