Backgroound Image

Cisco ISR Project – Guest network config (11 of ?)

Since offering a Guest Wifi network has become a pretty standard practice it’s something that will be added to the ISRs at the branch locations.  However, since this is a guest network it is untrusted and should not have access to the internal network.

The first step is to create a VRF for the guest network.  This will prevent traffic from the guest network from ever being exposed to the routes to the internal network.

vrf defInition IWAN-Guest

    address-family ipv4


The guest machines will require DHCP, so the router will be configured to hand out IPs.  For the DHCP range the was selected, and the IPs from 1 to 19 are excluded.  The Google DNS server at is set as the guest DNS server.

ip dhcp excluded-address vrf IWAN-Guest

ip dhcp pool IWAN-Guest

    vrf IWAN-Guest




 Next comes the class maps for traffic filtering.  We are going to allow DHCP and ICMP between the router and the guest network, as well as allow outbound traffic.  Based on the security needs ICMP can be removed, and the protocols allowed outbound can be restricted.

class-map type inspect match-any Guest-RTR-ICMP

    match access-group name Guest-ICMP-In

class-map type inspect match-any RTR-Guest-ICMP

    match access-group name Guest-ICMP-Out

class-map type inspect match-any Guest-RTR-DHCP

    match access-group name Guest-DHCP-In

   class-map type inspect match-any RTR-Guest-DHCP

 match access-group name Guest-DHCP-Out

class-map type inspect match-any Guest-Outside-Class

    match protocol dns

    match protocol http

    match protocol https

    match protocol ftp

    match access-group name Guest-Out

The policies are configured to pass DHCP traffic and inspect everything else.

Policy-map type inspect Guest-Outside-Policy

    class type inspect Guest-Outside-Class


    class class-default


Policy-map type inspect Guest-Self-Policy-In

    class type inspect Guest-RTR-DHCP


    class type inspect Guest-RTR-ICMP


    class class-default


Policy-map type inspect Guest-Self-Policy-Out

    class type inspect RTR-Guest-DHCP


    class type inspect RTR-Guest-ICMP


    class class-default


A zone will need to be created for the guest network

zone security Guest

The new zone will need to be configured to communicate with the router and internet zone, and the policies will need to be applied

zone-pair security Guest-Router source Guest destination self

    service-Policy type inspect Guest-Self-Policy-In

zone-pair security Router-Guest source self destination Guest

    service-Policy type inspect Guest-Self-Policy-Out

zone-pair security Guest-Internet source Guest destination Internet

    service-Policy type inspect Guest-Outside-Policy

 Next the guest interface will be created.  The VLAN 999 is being assigned for the guest network, and so a correlating subinterface will be created.  The IP used here needs to match the default gateway that was set earlier in the DNS settings

interface GigabitEthernet0/0/0.999

    description Guest-Network

    encapsulation dot1Q 999

    vrf forwardIng IWAN-Guest

    ip address

    ip nat inside

    zone-member security Guest

 Then a NAT statement is required to translate addresses.

ip nat inside source route-map NAT-Guest interface GigabitEthernet0/0/1 vrf IWAN-Guest overload

 A static route is needed to allow access to the outside network.

ip Route vrf IWAN-Guest GigabitEthernet0/0/1

A route map was used in the NAT statement to identify inside machines, so that route map needs to be created

Route-map NAT-Guest permit 10

    match ip address Guest-Internet

    match interface GigabitEthernet0/0/1

Lastly, we will create the ACLs.  Again, these ACLs can be adjusted to restrict traffic as needed.

ip access-list extended Guest-DHCP-In

    permit udp any eq bootpc any eq bootps


ip access-list extended Guest-DHCP-Out

    permit udp any eq bootps any eq bootpc


ip access-list extended Guest-ICMP-In

    permit icmp any any echo

    permit icmp any any echo-reply


ip access-list extended Guest-ICMP-Out

    permit icmp any any echo

    permit icmp any any echo-reply


ip access-list extended Guest-Internet

    deny ip

    deny ip

    deny ip

    permit ip any


ip access-list extended Guest-Out

    permit ip any

Now all that is needed is to assign the Guest SSID to VLAN 999 and configure switch ports accordingly.

Cisco ISR Project – NAT rules (10 of ?)

With the traffic rules in place next will come getting NAT rules set up.  In a nutshell Network Address Translation (NAT) is what converts internal IPs to public IPs, which allows internal machines to communicate on the internet.

With the IWAN design part of what I want to accomplish is to allow any internal site to be able to route through to another site in the event of an ISP failure.  To accomplish this the scope of the NAT rules will be expanded to cover all private IP ranges.  Getting NAT set up is pretty simple, though there are a number of steps.

  1. Define inside and outside interfaces
  2. Create ACL to define source machines
  3. Create route map for source machines
  4. Create NAT statement
  5. Create an ACL for traffic destined for inside
  6. Create route map to route traffic from internet to inside
  7. Apply the route map to the outside interface
  8. Create default route outbound

The NAT config will all be done via CLI, and it will all be from a config prompt.

The NAT inside interface would be the interface connected to the private side of your network, and the outside would be facing the public interface.  This is where the address translation will be taking place.  The interfaces in red may need to be modified to match your deployment.

int gi0/0/0  ip nat inside

 int gi0/0/1   ip nat outside

The next step is creating the ACL to define all inside networks.  Adjust this as needed.

ip access-list extended Inside_IPs

    permit ip any

    permit ip any

    permit ip any

Then a route map is created with the previous ACL and the interface being used.

route-map NAT-Inside permit 10

    match ip address Inside_IPs

    match interface GigabitEthernet0/0/1

 Next would be NAT statement.  In it we specify that traffic from the inside interface that matches the route map is translated to the outside interface (and uses the IP of that interface), and “overload” means that it will be a many-to-one NAT.  Since it is many-to-one we are allowing multiple inside machines to use the single outside IP, and the router tracks the traffic by altering the source port and matching the return traffic.

ip nat inside source route-map NAT-Inside interface GigabitEthernet0/0/1 overload

That concludes the actual NAT portion, but without the related routing it really doesn’t help.  So there are two routes that are needed.  One to get the traffic out and the other to get traffic back in.  We’ll start with the return traffic. First we need a ACL to define the traffic coming back in.

ip access-list extended InternalNetworks

    permit ip any

    permit ip any

    permit ip any

Then we create a route map for it.

route-map Internet-Internal permit 10

    description Return routing for Local Internet Access

    match ip address InternalNetworks

    set global

That route map is then applied to our external interface

interface GigabitEthernet0/0/1

     ip policy route-map Internet-Internal

The last step is to create the default route from the inside to get to the outside.

ip route GigabitEthernet0/0/1 Next_Hop_IP

Now internal machines should have internet access.  Here are a few commands that help with troubleshooting if there are issues:

show ip nat translation (shows current NAT translations)

clear ip nat translation * (clears all current translations, which is helpful if the NAT statement needs to be changed.)

Cisco ISR Project – Router access rules (9 of ?)

Now that most connectivity has been configured the next step will be creating access rules to restrict access as needed, as well as grant access where needed.  This is going to primarily apply to the branch routers, but the HQ routers can (and should) be configured similarly.

Before we get into what that means let’s cover how this is going to work.

Much to my chagrin, gone are the days of the “permit any any established” rules.  Those have been replaced with packet inspection to perform the stateful firewall feature.  What this means is that inbound packets are inspected to see if they match an existing outbound flow.  If the traffic is part of an established flow then it is allowed.  If not, then it’s dropped.

This gets a bit more complicated with the addition of the Zone-based Firewall (ZBF) in the ISR.  Instead of applying rules to the interface they are applied to the zone pairs.

Here’s the high level flow.

  1. Class maps are created (and specify ACLs as needed)
  2. Policy maps are created (and specify class maps as needed)
  3. Security zones are created
  4. Zone pairs are created, with source and destination specified, then the policy map is applied
  5. Interfaces are assigned to security zones
  6. ACLs are created for traffic definitions

Maybe a diagram will help.  This diagram shows the commands needed to allow traffic to flow from the inside IP range of from the inside interface Gi0/0/0 to any IP on the outside interface Gi0/0/1.  Lines in red are the commands.

Access Control

For the ISR deployment there are a number of rules that we need to allow for the creation of VPN tunnels on the external interfaces.  Now, let’s get to what the basic config will look like.

This is all CLI commands, so you will need to be at a config prompt.  The first command is simply logging packets that are dropped by the policies.

parameter-map type inspect global

 log dropped-packets

The next step will be class maps.  There are five maps, inside to outisde, and then both pass and inspect traffic between the outside and the router.

class-map type inspect match-any Inside-Outside-Class

    match protocol ftp

    match protocol icmp

    match protocol udp

    match protocol tcp

class-map type inspect match-any Inspect-ACL-Out-Class

    match access-group name ACL-RTR-Out

class-map type inspect match-any PASS-ACL-In-Class

    match access-group name ESP-In

    match access-group name GRE-In

class-map type inspect match-any PASS-ACL-Out-Class

    match access-group name ESP-Out

class-map type inspect match-any Inspect-ACL-In-Class

    match access-group name ACL-RTR-In

Next comes the policy maps.  These are the policies that specify the classes that were just created.

Policy-map type inspect Inside-Outside-Policy

    class type inspect Inside-Outside-Class


    class class-default


Policy-map type inspect ACL-In-Policy

    class type inspect Inspect-ACL-In-Class


    class type inspect PASS-ACL-In-Class


    class class-default


Policy-map type inspect ACL-Out-Policy

    class type inspect Inspect-ACL-Out-Class


    class type inspect PASS-ACL-Out-Class


    class class-default


By looking at the policies it’s easy to see that we will be passing inbound ESP and GRE traffic (the ACLs will follow), as well as outbound ESP traffic.  Everything else that is allowed through the ACLs will be inspected.

The next step will be to create the security zones for the ZBF.

zone security Internet

zone security MPLS

zone security default

For now we are just creating a zone for each connection type.  More zones will be added later as the config is built out.

Now that the zones are created we create zone pairs, which link a source and destination zone and apply one of the policies that were created to the traffic between those zones.  One thing to be aware of is the router itself uses the “Self” zone.  That means that traffic to the router will use the “Self” zone, so we can use that in the zone pairs.

zone-pair security Router-Internet source self destination Internet

    service-Policy type inspect ACL-Out-Policy

zone-pair security Router-MPLS source self destination MPLS

    service-Policy type inspect ACL-Out-Policy

zone-pair security Inside-Internet source default destination Internet

    service-Policy type inspect Inside-Outside-Policy

zone-pair security Inside-MPLS source default destination MPLS

    service-Policy type inspect Inside-Outside-Policy

zone-pair security Internet-Router source Internet destination self

    service-Policy type inspect ACL-In-Policy

zone-pair security MPLS-Router source MPLS destination self

    service-Policy type inspect ACL-In-Policy

The next step is to associate the interfaces with the corresponding security zones.  Since there are only two actual zones (Internet and MPLS) this is pretty straightforward.  All the other interfaces are using the default zone for now.  Replace the interface in red with the correct interface for your deployment.

int gi0/0/1

    zone-member security Internet

int gi0/0/2

    zone-member security MPLS

Now the only thing left to do would be to create the ACLs.  The ACLs here are based off a Cisco IWAN document.  There are a number of areas where they can be tweaked.  The obvious change would be disabling ICMP if that is a requirement for your environment.  Another change would be to put in specific addresses instead of “any” for the VPN related rules.  I would strongly recommend making at least the inbound rules more restrictive.

ip access-list extended ACL-RTR-In

    permit udp any any eq non500-isakmp

    permit udp any any eq isakmp

    permit icmp any any echo

    permit icmp any any echo-reply

    permit icmp any any ttl-exceeded

    permit icmp any any port-unreachable

    permit udp any any gt 1023 ttl eq 1

ip access-list extended ACL-RTR-Out

    permit udp any any eq non500-isakmp

    permit udp any any eq isakmp

    permit icmp any any

    permit tcp any any eq 8080

    permit udp any any eq domain

ip access-list extended ESP-In

    permit esp any any

ip access-list extended ESP-Out

    permit esp any any

ip access-list extended GRE-In

    permit gre any any

Now that these rules are in place the routers should still establish the VPN tunnels, and traffic from the outside world should be restricted.