The Cisco Zone-based firewall was derived from the old “firewall feature set” and allows the administrator to define firewall rules based on zones, where each zone may contain one or more logical interfaces. Using Cisco’s zone-based firewall isn’t as easy as many other solutions (e.g. Juniper SRX, Cisco ASA), and recently I needed to configure one which was to pass both IPv4 and IPv6 services. Here’s an example of how it’s done.
Some of the difficulties arise from the fact that you still need to define access-lists along with class and policy objects. Once you’ve got a template and some examples done, then it gets a lot easier. This would be a great candidate for an automation solution such as using Ansible to generate and update the policy. Maybe at some stage in the future I’ll post the Ansible solution, but for now it’s done by hand – mostly because I’ve yet to meet anyone using IOS ZBFW at such a scale that automation would be beneficial.
In the example below, I have got an IOS router at the edge of a typical network which is performing IPv4 NAT behind a single public IPv4 address configured on it’s Dialer1 interface. The router is routing public IPv6.
The internal IPv4 address for the internal SMTP and HTTP server will be 192.168.1.99.
IPv6 is also enabled and a /64 public subnet is routing through without NAT (of course). The requirement is that we want to allow incoming HTTP, HTTPS, and SMTP from all Internet hosts to servers on the inside network for both IPv4 and IPv6.
Here’s the example:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 |
! ! Class maps for http & https ! www = http|https ! class-map type inspect match-any www match protocol http match protocol https class-map type inspect match-all www-ipv6-in match class-map www match access-group name www-ipv6-in class-map type inspect match-all www-ipv4-in match class-map www match access-group name www-ipv4-in ! ! Class maps for smtp ! class-map type inspect match-all smtp-ipv4-in match protocol smtp match access-group name smtp-ipv4-in class-map type inspect match-all smtp-ipv6-in match protocol smtp match access-group name smtp-ipv6-in class-map type inspect match-any smtp-in match class-map smtp-ipv4-in match class-map smtp-ipv6-in ! ! Policy map for http & smtp ! policy-map type inspect Internet-Internal-policy class type inspect www-in inspect class type inspect smtp-in inspect class class-default drop ! ! Access lists for IPv4 ! ip access-list extended smtp-ipv4-in permit tcp any host 192.168.1.99 eq smtp ! ip access-list extended www-ipv4-in permit tcp any host 192.168.1.99 eq www permit tcp any host 192.168.1.99 eq 443 ! ! Access lists for IPv6 ! ipv6 access-list smtp-ipv6-in sequence 30 permit tcp any host 2001:470:1F05:AEB::29 eq smtp ! ipv6 access-list www-ipv6-in sequence 50 permit tcp any host 2001:470:1F05:AEB::28 eq www permit tcp any host 2001:470:1F05:AEB::28 eq 443 ! ! Interface NAT rules: ! ip nat inside source static tcp 192.168.1.99 80 interface Dialer1 80 ip nat inside source static tcp 192.168.1.99 443 interface Dialer1 443 ip nat inside source static tcp 192.168.1.99 25 interface Dialer1 25 ! |
Some things to note here:
- I always create extended access lists for incoming services. This gives me the flexibility to deny specific hosts access to the service, or other refinements, if I need to in the future without messing around with the policy map.
- I’ve had issues with the SMTP inspection cutting off Emails – particularly those with fairly large document attachments. This causes the postfix server and the sending client to go into a crazy sort of retry loop. If you have problems then remove the statement match protocol smtp from both of the smtp class maps.
- Re-ordering the rules in the policy map is really a major pain. There’s no simple way of doing it apart from copying the whole policy map into a text editor, making the changes, and then deleting the current and posting the updated one back in. An unfortunate side-effect of doing this is that the policy map will get removed from the zone-pair service-policy definition, and that will need to be re-entered as well:
Watch out if your management access to the device is also going though that policy map and zone pair.1234!zone-pair security Internet-Internal source Internet destination Internalservice-policy type inspect Internet-Internal-policy!
