Month: May 2016

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

    exit-address-family

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

ip dhcp excluded-address vrf IWAN-Guest 192.168.254.1 192.168.254.19

ip dhcp pool IWAN-Guest

    vrf IWAN-Guest

    network 192.168.254.0 255.255.255.0

    default-Router 192.168.254.1

    dns-server 8.8.8.8 

 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

    inspect

    class class-default

    drop

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

    class type inspect Guest-RTR-DHCP

    pass

    class type inspect Guest-RTR-ICMP

    inspect

    class class-default

    drop

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

    class type inspect RTR-Guest-DHCP

    pass

    class type inspect RTR-Guest-ICMP

    inspect

    class class-default

    drop

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 192.168.254.1 255.255.255.0

    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 0.0.0.0 0.0.0.0 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 192.168.254.0 0.0.0.255 192.168.0.0 0.0.255.255

    deny ip 192.168.254.0 0.0.0.255 172.16.0.0 0.15.255.255

    deny ip 192.168.254.0 0.0.0.255 10.0.0.0 0.255.255.255

    permit ip 192.168.254.0 0.0.0.255 any

!

ip access-list extended Guest-Out

    permit ip 192.168.254.0 0.0.0.255 any

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

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 10.0.0.0/8 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

    inspect

    class class-default

    drop

Policy-map type inspect ACL-In-Policy

    class type inspect Inspect-ACL-In-Class

    inspect

    class type inspect PASS-ACL-In-Class

    pass

    class class-default

    drop

Policy-map type inspect ACL-Out-Policy

    class type inspect Inspect-ACL-Out-Class

    inspect

    class type inspect PASS-ACL-Out-Class

    pass

    class class-default

    drop

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.