FAQs About Firewall Services
This section answers the following questions about firewall services:
Q. Why do I lose my connection after I deploy my firewall rules to a device?
Security Manager does not check whether the firewall rules that you configured in Security Manager permit management traffic (SSH and HTTPS) to the device being managed. As a result, after you deploy firewall rules to the device, connection to the device might be lost. Therefore, we strongly recommend that your access rules policies contain a global rule that permits Security Manager to access the device. Keep in mind that when you create an access rule policy, the device creates an implicit deny any rule at the end of your explicit rules.
Q. Why does the Hit Count report not show standard ACLs for my IOS device?
The purpose of the Hit Count tool is to show statistics related to the access rules defined in Security Manager and deployed to the device. Do not use the Hit Count tool until after you use Security Manager to deploy the configuration to the device. Because Security Manager deploys only extended ACLs for the access rules policy, results are displayed only for extended ACLs.
Q. Why does the CLI supporting HTTP for authentication proxy remain on the device after I unassign the policy?
IOS devices require that HTTP be used as the traffic type for authentication proxy, which generates the command ip http server. Security Manager does not remove the CLI after you unassign the authentication proxy policy from the device in Security Manager. If you do not require HTTP access for other purposes to the IOS device, you can manually remove the CLI or create a FlexConfig object to remove the CLI from the device.
Q. Why can I not deploy my access rules policies for the BGP routing protocol to 87x routers?
IOS 87x ISR routers do not support BGP as a routing protocol or as a service in ACLs if the device has only 24 MB of memory; however, BGP is supported if the device has more than 24 MB of memory. Security Manager does not detect the amount of memory available on the device and cannot enforce any restrictions. As a result, deploying a job containing an access rule for BGP fails. If you create an ACL with a single ACE containing BGP, an empty ACL is created on the device, which you can remove manually.
Q. Why is an ACE removed from the ACL even though it is bound to the interface?
If you import or discover a PIX 6.3 device that has an ACE with the “interface” keyword, then you deploy to the same device without making any changes, the ACE might be removed from the ACL even though it is bound to the interface by the access-group command. This can occur if the ACL has other ACEs, or the ACL contains only the ACEs using the “interface” keyword. The access-group command for the ACL is removed from the device.
Q. How do I create an firewall rule that permits a range of addresses, as defined in a network/host object, but negates selected addresses within that range?
It is not possible to create a network object that includes a range but excludes certain addresses within that range. Instead, create two rules. The first rule should define those addresses that you want to deny. You can create a network/host object for that purpose. The second rule, which should immediately follow the first, should define the range of permitted addresses, as defined in the other network/host object.
Q. How do I configure the management IP of a security context in transparent mode without going to the device to configure it?
This requires a two-step process. First, you must configure and deploy a management IP policy to the security context. You can then configure the device properties of the security context so that Security Manager uses the management IP to communicate directly with the security context.
Step 1 In the Device selector, select the security context, then select Platform > Bridging > Management IP in the Policy selector.
Step 2 Enter the management IP address and network mask, then click Save.
Step 3 Submit and deploy your changes. Deployment to the security context is performed through the system execution space. The management IP is now configured on the device.
Step 4 In the Device selector, right-click the security context and select Device Properties.
Step 5 On the General page, enter the management IP address in the IP Address field.
Step 6 Click Credentials to display the Credentials page.
Step 7 Enter the credentials for the security context, then click Save. Security Manager can now communicate directly with the security context.