if i need to make any changes to the stateful firewall (acl ingress or myfw), i simply do the following:
no ip inspect myfw out
no ip access-group ingress in
make my changes and add the 2 lines above back in under the interface outside. clients connected would not lose their connections to the internet, and i would not lose my PUTTY session to the router.
with the new style zone based firewall, you can use the self zone to control router access. you would have something like this:
! zone-pair security pub-self source public destination self service-policy type inspect to-self-pmap zone-pair security self-pub source self destination public service-policy type inspect from-self-pmap
zone-pair security pub-priv source public destination private service-policy type inspect pub-priv-policy interface outside
zone-member security public
to change anything on the firewall, i would do the following:
take the affected interface out of the affected zone, make my changes in the policy/class maps, reapply the interfaces to the zones. this is where i would lose the putty connection to the router. for example, if i want to change the self zone firewall/acl, i would have to take the interfaces out of the zones, make my changes and reapply the interfaces back into the zones. however i am not able to complete the tasks of adding interfaces back into the zones without losing SSH connection to the router - sometimes the connection lost is permanent. what am i doing wrong?
When an interface is a part of a zone then it cannot talk to non-zoned interfaces.
So while configuring, if you put the interface you are behind behind a zone, it will not be able to go to any other interfaces unless it is in a zone and the corresponding zone pair allows it.
Also, if you have zone pairs that have the self zone in them, then the moment you put an interface behind a zone that is in a zone pair with the self zone your management traffic will be subject to the policies of that pair. So if you missed something in the policy you could lock yourself out
My suggestion would be to configure zone pairs for self to your interface zone and your interface zone and self. Then match on management traffic (telnet or ssh) and "pass" that traffic with ZBF for both zone-pars. Then put your interface behind your zone. Zone to self and self to zone is passed so the router should be still manageable with ssh or telnet.
Then you can keep on setting up ZBF.
Keep the "reload in xxx" minutes command without saving the config which you could use before putting the zone membership is so that the router will reload if you lock yourself out. "reload cancel" will cancel the reload.
First: the "IOS Classic Firewall" never inspected traffic to or from the router, that is clearly documented.
In a zone based firewall the policy actions are handled in a special way if the self zone is affected:
Any zone can communicate with the self zone and vice verse if no zone pair is defined regardless whether the source or destination is member of any zone.
- If the a zone pair is defined, which includes the self zone and any other zone and no policy is attached you can still communicate
- policy actions are only enforced if a zone pair exists which includes the self zone and any other zone and a policy is attached
which means: as soon as you attach a policy to the zone pair e.g. pub-self the inspection will kick in, invalidating a previously established ssh sesion from the zone public.
To keep your ssh session you could try to define a class map which selects ssh and within the policy map you use the action pass instead of inspect for this class to permit packets unconditionally (without inspection). You would also need another zone pair self-pub which unconditionally passes the ssh return traffic.
If you loose the connection permanently (you cannot reconnect) then you should review your class-maps and policy-maps.
Alternatively to the self zone you can use the control-plane with port filters and or policy maps but this is a totally diferent story
I recommend the feature guide for control-plane especially:
Control-plane host subinterface—Subinterface that receives all control-plane IP traffic that is directly destined for one of the router interfaces. Examples of control-plane host IP traffic include tunnel termination traffic, management traffic, or routing protocols such as SSH, SNMP, BGP, OSPF, and EIGRP. All host traffic terminates on and is processed by the router. Most control-plane protection features and policies operate strictly on the control-plane host subinterface. Since most critical router control-plane services, such as routing protocols and management traffic, are received on the control-plane host subinterface, it is critical to protect this traffic through policing and protection policies. CoPP, port-filtering, and per-protocol queue thresholding protection features can be applied on the control-plane host subinterface.
update: here is a nice presentation on zone based firewalls (zone self is on slide 15):
if i simply want to allow client to get on to the web, i just need 2 zones (priv and pub), and only 1 zone pair (priv-pub)?
if i would also need vpn and control access to the router, i would need 3 zones (priv, pub, and self), and 4 zone pairs (priv-self, self-pub, pub-self, and self-priv)? further more, access control to the router will fall under the pub-self and self-pub zone pairs, vpn class map/policy will fall under all 4 zone pairs?
thanks. it appears that the control plane security features are extensive. it appears that i can use ZFW for the priv and pub zones, while using control plane to control access to the router. can anyone provide a link to or a quick example? for example, only allow ssh, icmp, http, https from host 220.127.116.11 while allowing vpn from anywhere.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in HA
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationCo...
I am currently unable to specify "crypto keyring" command when configuring VPN connection on my cisco 2901 router.
The following licenses have been activated on my router :