Cisco – How Not to Route on a Cisco Router

ciscointerfacerouterroutingvlan

So we have a router, with a switch card interface, 8 ports

Say I have 4 VLANs (A,B,C,D) on it, with 2 switch ports in each.

Each VLAN (i.e. all ports) can communicate with each other, because naturally they are all connected to the one router…

But say I only wanted A & C, and B & D, to be able to see and communicate with each other, how would this be done?

I was thinking possible NAT, but I'm sure there's some industry standard way of doing it?

Best Answer

While Ron and Ron's answers actually enable routing but prevent traffic, their suggestions still pack both host groups into the same routing instance.

There's another way to think about this:

a) VRF-lite

This essentially creates two almost completely (well, they share the hardware ressources...) separated routing instances in one box.

Things might get a bit tricky (but not impossible) if both VRFs are to share the same (single) internet access and "upstream" interface. But you actually didn't ask about that. Some licensing might be required to allow to configure VRF-lite, depending on the model.

Also, if you'd still like to allow some traffic from one VRF to the other, things tend to get a bit messy (route leaking, earring cables and things like that), that will bleak out the nice VRF separation we just established with purpose. Don't pursue the VRF-lite approach in that case.

Here's what to do for VRF-lite:

! 
! Define two VRF instances
!
vrf definition VRF_AandC
 address-family ipv4
 exit-address-family

vrf definition VRF_BandC
 address-family ipv4
 exit-address-family

!
! the L2 VLANs
! 
vlan11
 name VLAN-A
vlan 12
 name VLAN-B
vlan 13
 name VLAN-C
vlan 14
 name VLAN-D

!
! map the switch ports to their VLAN
!
! assuming the interfaces of the switch modules are named GigabitEthernet1-8
!

interface GigabitEthernet 1
 descripton * Access Port into VLAN-A *
 switchport mode access
 switchport access vlan 11
 spanning-tree portfast
interface GigabitEthernet 2
 descripton * Access Port into VLAN-A *
 switchport mode access
 switchport access vlan 11
 spanning-tree portfast
!
interface GigabitEthernet 3
 descripton * Access Port into VLAN-B *
 switchport mode access
 switchport access vlan 12
 spanning-tree portfast
interface GigabitEthernet 4
 descripton * Access Port into VLAN-B*
 switchport mode access
 switchport access vlan 12
 spanning-tree portfast
!
interface GigabitEthernet 5
 descripton * Access Port into VLAN-C *
 switchport mode access
 switchport access vlan 13
 spanning-tree portfast
interface GigabitEthernet 6
 descripton * Access Port into VLAN-C *
 switchport mode access
 switchport access vlan 13
 spanning-tree portfast
!
interface GigabitEthernet 7
 descripton * Access Port into VLAN-D *
 switchport mode access
 switchport access vlan 14
 spanning-tree portfast
interface GigabitEthernet 8
 descripton * Access Port into VLAN-D *
 switchport mode access
 switchport access vlan 14
 spanning-tree portfast


!
! the L3 interfaces into the VLANs
! are attached to their respective VRF
!
interface vlan 11
 vrf forwarding VRF_AandC
 ip address <ip.ip.AAA.ip> <mask.mask.mask.mask>

interface vlan 12
 vrf forwarding VRF_BandD
 ip address <ip.ip.BBB.ip> <mask.mask.mask.mask>

interface vlan 13
 vrf forwarding VRF_AandC
 ip address <ip.ip.CCC.ip> <mask.mask.mask.mask>

interface vlan 14
 vrf forwarding VRF_AandC
 ip address <ip.ip.DDD.ip> <mask.mask.mask.mask>

b) Zone based firewalling

Essentially the same as the Rons proposed, but there's an advanced way with a lot more text and config items. This may require a SEC license on your router.

The key points about ZBFW are:

  • interfaces belong to zones
  • no in/out ACLs on the interfaces themselves
  • interfaces of the same zone have no restrictions
  • no communication between "zoned" and "non-zoned" interfaces
  • stateful: filtering definitions (ACLs for the class-maps) only need to cover the initiator-to-responder direction.
  • application awareness: SIP, FTP, and the usual suspects can be inspected, and ports open dynamically
  • filtering and protocol inspection occurs s w/regards to Src and Dst zones, not interfaces.

I made some assumptions, based on what you let us know so far. I took some liberties, which might actually be beyond your question's scope. I think you'll spot the parts that don't actually apply to your given situation.

  • There is one "external" interface/subnet ("Behold, the Internet!") with a single public IP address.
  • there's four "internal" subnets/VLANs A,B,C and D
  • Subnets A and C should be able to communicate unrestrictedly
  • Subnets A and C should have some general purpose internet access and a few port forwardings to hosts in A and C
  • Subnets B and D should be able to communicate unrestrictedly
  • Subnets B and D should have some general purpose internet access and a few port forwardings to hosts in B and D
  • Communication from (A OR C) to/from (B OR D) must not be allowed.

The config items will now come in a different order than they should be applied. IOS will bark if you paste them in this order. I do this deliberately, to make the configuration layers of ZBFW a bit more clear. (in real life, do it bottom-up: ACLs, class-maps, policy-maps, zones, zone-pairs, interfaces-to-zones).

Please note: half of this comes from a real life setup, half is composed freehandedly. Please point me to any typos or item misspelled config item names.

Let's start with defining zones. A zone may span mutliple Layer 3 interfaces of a given router, but one interface may only ever be part of exactly one zone. 

zone security Z-INTERNET
 description * the outside world *
zone security Z-AC
 description * VLANs/Subnets A and C *
zone security Z-BD
 description * VLANs/Subnets A and C *

The interfaces need to be assigned to a zone. In the real world, you'd to this at the very end - else you'd impact traffic already flowing through the router. The nat inside/outside bits are already there, too. 

 interface vlan 11
  ip nat inside
  zone-member security Z-AC

 interface vlan 12
  ip nat inside 
  zone-member security Z-BD

  interface vlan 13
  ip nat inside
  zone-member security Z-AC

 interface vlan 14
  ip nat inside 
  zone-member security Z-BD

 interface <outsideIF>
  ip address <some.possibly.public.ip> <mask>
  ip nat outside
  zone-member security Z-INTERNET

Then, we need some zone-pairs, and each has its own service policy applied. A zone-pair is unidirectional; you only need one if you have traffic patterns initiating in the given direction. Note the absence of a zone-pair defintion for AC-to-BD and BD-to-AC.

zone-pair security AC-TO-INTERNET source Z-AC destination Z-INTERNET
 service-policy type inspect PMAP-AC-TO-INTERNET-TRAFFIC

zone-pair security INTERNET-TO-AC source Z-INTERNET destination Z-AC
 service-policy type inspect PMAP-INTERNET-TO-AC-TRAFFIC

zone-pair security BD-TO-INTERNET source Z-BD destination Z-INTERNET
 service-policy type inspect PMAP-BD-TO-INTERNET-TRAFFIC

zone-pair security INTERNET-TO-BD source Z-INTERNET destination Z-BD
 service-policy type inspect PMAP-INTERNET-TO-BD-TRAFFIC

And now we need multiple MQC constructs with policy-map, class-map and access-list, as we all love or hate them from QoS. You'll notice that I may be overdoing it a little with having an almost complete policy-map/class-map/access-list tuple per zone-pair, with little re-use of common items. That's how I think - can't help it.

The policy maps of "type inspect" define what is to happen to the different classes of traffic: pass, inspect or drop. Each zone-pair gets its own policy map (see above). 

policy-map type inspect PMAP-INTERNET-TO-AC-TRAFFIC
 class type inspect CMAP-COMMON-TRACE-TRAFFIC
  pass
 class type inspect CMAP-INTERNET-TO-AC-TRAFFIC
  inspect
 class class-default
  drop log

policy-map type inspect PMAP-INTERNET-TO-BD-TRAFFIC
 class type inspect CMAP-COMMON-TRACE-TRAFFIC
  pass
 class type inspect CMAP-INTERNET-TO-BD-TRAFFIC
  inspect
 class class-default
  drop log

 policy-map type inspect PMAP-AC-TO-INTERNET-TRAFFIC
 class type inspect CMAP-COMMON-TRACE-TRAFFIC
  pass
 class type inspect CMAP-AC-TO-INTERNET-STANDARD-TRAFFIC
  inspect
 class class-default
  drop log

policy-map type inspect PMAP-BD-TO-INTERNET-TRAFFIC
 class type inspect CMAP-COMMON-TRACE-TRAFFIC
  pass
 class type inspect CMAP-BD-TO-INTERNET-STANDARD-TRAFFIC
  inspect
 class class-default
  drop log

Of course we have to define what classes of traffic we consider. That's done with class-maps of "type inspect" and a few ACLs (matching on "protocol" also works).

First, a few item's we'll be reusing (note the "COMMON" in the config item name)

class-map type inspect match-any CMAP-COMMON-TRACE-TRAFFIC
  match access-group name ACLv4-COMMON-ICMP-AND-TRACE

ip access-list extended ACLv4-COMMON-ICMP-AND-TRACE
 permit icmp any any time-exceeded
 permit icmp any any ttl-exceeded
 permit icmp any any unreachable
 permit icmp any any administratively-prohibited
 permit icmp any any packet-too-big
 permit icmp any any echo
 permit icmp any any echo-reply

ip access-list extended ACLv4-COMMON-STANDARD-TRAFFIC
 ! well in this example, we're allowing almost anything out 
 permit tcp any any
 permit udp any any

Then, each per-zone-pair policy-map gets its specific class map. Again, you'll notice that there is no class-map defining traffic allowed to go from AC to BD or vice-versa.

Internet to/from AC:

class-map type inspect match-any CMAP-AC-TO-INTERNET-STANDARD-TRAFFIC
 match access-group name ACLv4-COMMON-STANDARD-TRAFFIC

class-map type inspect match-any CMAP-INTERNET-TO-AC-TRAFFIC
 match access-group name ACLv4-INTERNET-TO-AC-TRAFFIC

ip access-list extended ACLv4-INTERNET-TO-AC-TRAFFIC
 ! note: destination IP and port as seen AFTER DstNAT and port translation
 permit tcp any host <ip.ip.AAA.ip> eq <port>
 permit tcp any host <ip.ip.AAA.ip> eq <port>
 permit udp any host <ip.ip.CCC.ip> eq <port>

Internet to/from BD:

class-map type inspect match-any CMAP-INTERNET-TO-BD-TRAFFIC
 match access-group name ACLv4-INTERNET-TO-BD-TRAFFIC

ip access-list extended ACLv4-INTERNET-TO-BD-TRAFFIC
 ! note: destination IP and port as seen AFTER DstNAT and port translation
 permit tcp any host <ip.ip.BBB.ip> eq <port>
 permit tcp any host <ip.ip.DDD.ip> eq <port>
 permit udp any host <ip.ip.DDD.ip> eq <port>

class-map type inspect match-any CMAP-BD-TO-INTERNET-STANDARD-TRAFFIC
 match access-group name ACLv4-COMMON-STANDARD-TRAFFIC

So much for ZBFW. Some of the items need to be kept coordinated with the given NAT/portfowarding setup.

Here's the NATty things to do, with NAT overload to the outside interface, and a handful of port forwardings back in.

ip access-list extended ACLv4-NAT-TO-INTERNET
 permit ip ip.ip.AAA.0 0.0.0.<wildcard bits>
 permit ip ip.ip.BBB.0 0.0.0.<wildcard bits>
 permit ip ip.ip.CCC.0 0.0.0.<wildcard bits>
 permit ip ip.ip.DDD.0 0.0.0.<wildcard bits>

ip nat inside source list ACLv4-NAT-TO-INTERNET interface <outsideIF> overload 
ip nat inside source static tcp <ip.ip.AAA.ip> <dstPortOnInside> interface <outsideIF> <dstPortOnOutside>
ip nat inside source static tcp <ip.ip.AAA.ip> <dstPortOnInside> interface <outsideIF> <dstPortOnOutside>
ip nat inside source static udp <ip.ip.CCC.ip> <dstPortOnInside> interface <outsideIF> <dstPortOnOutside>
ip nat inside source static tcp <ip.ip.BBB.ip> <dstPortOnInside> interface <outsideIF> <dstPortOnOutside>
ip nat inside source static tcp <ip.ip.DDD.ip> <dstPortOnInside> interface <outsideIF> <dstPortOnOutside>
ip nat inside source static udp <ip.ip.DDD.ip> <dstPortOnInside> interface <outsideIF> <dstPortOnOutside>

ADDON:

In your comment, you mentioned "SBC" - as in Session Border Controller, I presume? This might call for the introduction of the "SELF" zone, if traffic/service is to be terminated on the router itself. I can't help there - haven't worked with it. One ressource for it: https://community.cisco.com/t5/security-documents/zbfw-self-zone-integration/ta-p/3154572

The Self-Zone:

Is the FW zone that includes all of the Router interfaces IP addresses (even for interfaces not attached to any specific zone).

You must think of the self-zone as the router itself so when we configure a policy including the Self-zone is related to:

 -Traffic to the router

 -Traffic from the router

So when someone asks the following

 What Traffic Should I Consider When I Deal With The Self-Zone?

      You should answer:

           -Managment plane traffic (SSH,Telnet,etc)

           -Control plane traffic(Routing Protocols)
Related Topic