How not to route on a Cisco router

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
4
down vote

favorite












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?






cisco routing router vlan interface







share|improve this question









New contributor




user10021657 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.























    up vote
    4
    down vote

    favorite












    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?






    cisco routing router vlan interface







    share|improve this question









    New contributor




    user10021657 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.





















      up vote
      4
      down vote

      favorite









      up vote
      4
      down vote

      favorite











      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?






      cisco routing router vlan interface







      share|improve this question









      New contributor




      user10021657 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      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?






      cisco routing router vlan interface




      cisco routing router vlan interface






      share|improve this question









      New contributor




      user10021657 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      share|improve this question









      New contributor




      user10021657 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      share|improve this question




      share|improve this question








      edited yesterday









      Ron Maupin♦

      56.2k94695




      56.2k94695






      New contributor




      user10021657 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      asked yesterday









      user10021657

      312




      312




      New contributor




      user10021657 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      user10021657 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      user10021657 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.




















          3 Answers
          3






          active

          oldest

          votes

















          up vote
          9
          down vote













          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)






          share|improve this answer


















          • 1




            Great Rons think alike :)
            – Ron Maupin♦
            yesterday










          • it would actually be for an SBC (we have the Cube licence) and some basic firewalling (ACL's and NAT aswell) ....I'd be interested to see what you propose
            – user10021657
            yesterday

















          up vote
          4
          down vote













          You can simply create access lists to restrict traffic, and place those access lists on the VLAN interfaces.



          For example an ACL to prevent traffic from 10.11.12.0/24 to 10.11.13.0/24 can be created and placed on the VLAN interface for the 10.11.12.0 network:



          ip access-list 12 deny 10.11.13.0 0.0.0.255
          ip access-list 12 permit any
          !
          interface VLAN 12
           ip access-group 12 in
          !


          The direction (in or out) is from the perspective of the router, not the network.



          You could also create an ACL to place on the VLAN for the 10.11.13.0 network:



          ip access-list 13 deny 10.11.12.0 0.0.0.255
          ip access-list 13 permit any
          !
          interface VLAN 13
           ip access-group 13 out
          !





          share|improve this answer





























            up vote
            3
            down vote













            Hi and welcome to Network Engineering! We hope you will become a contributing member of this community.



            The simplest way to do this is with access lists. They are essentially filters that can block specific source or destination addresses.



            You could create an access list and apply it to Vlan A that only allows traffic to B, and blocks traffic to C and D.






            share|improve this answer




















              Your Answer







              StackExchange.ready(function()
              var channelOptions =
              tags: "".split(" "),
              id: "496"
              ;
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function()
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled)
              StackExchange.using("snippets", function()
              createEditor();
              );

              else
              createEditor();

              );

              function createEditor()
              StackExchange.prepareEditor(
              heartbeatType: 'answer',
              convertImagesToLinks: false,
              noModals: false,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: null,
              bindNavPrevention: true,
              postfix: "",
              noCode: true, onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              );



              );






              user10021657 is a new contributor. Be nice, and check out our Code of Conduct.









               

              draft saved


              draft discarded


















              StackExchange.ready(
              function ()
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f53193%2fhow-not-to-route-on-a-cisco-router%23new-answer', 'question_page');

              );

              Post as a guest

















              3 Answers
              3






              active

              oldest

              votes








              3 Answers
              3






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes








              up vote
              9
              down vote













              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)






              share|improve this answer


















              • 1




                Great Rons think alike :)
                – Ron Maupin♦
                yesterday










              • it would actually be for an SBC (we have the Cube licence) and some basic firewalling (ACL's and NAT aswell) ....I'd be interested to see what you propose
                – user10021657
                yesterday














              up vote
              9
              down vote













              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)






              share|improve this answer


















              • 1




                Great Rons think alike :)
                – Ron Maupin♦
                yesterday










              • it would actually be for an SBC (we have the Cube licence) and some basic firewalling (ACL's and NAT aswell) ....I'd be interested to see what you propose
                – user10021657
                yesterday












              up vote
              9
              down vote










              up vote
              9
              down vote









              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)






              share|improve this 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)







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited yesterday

























              answered yesterday









              Marc 'netztier' Luethi

              1,535311




              1,535311







              • 1




                Great Rons think alike :)
                – Ron Maupin♦
                yesterday










              • it would actually be for an SBC (we have the Cube licence) and some basic firewalling (ACL's and NAT aswell) ....I'd be interested to see what you propose
                – user10021657
                yesterday












              • 1




                Great Rons think alike :)
                – Ron Maupin♦
                yesterday










              • it would actually be for an SBC (we have the Cube licence) and some basic firewalling (ACL's and NAT aswell) ....I'd be interested to see what you propose
                – user10021657
                yesterday







              1




              1




              Great Rons think alike :)
              – Ron Maupin♦
              yesterday




              Great Rons think alike :)
              – Ron Maupin♦
              yesterday












              it would actually be for an SBC (we have the Cube licence) and some basic firewalling (ACL's and NAT aswell) ....I'd be interested to see what you propose
              – user10021657
              yesterday




              it would actually be for an SBC (we have the Cube licence) and some basic firewalling (ACL's and NAT aswell) ....I'd be interested to see what you propose
              – user10021657
              yesterday










              up vote
              4
              down vote













              You can simply create access lists to restrict traffic, and place those access lists on the VLAN interfaces.



              For example an ACL to prevent traffic from 10.11.12.0/24 to 10.11.13.0/24 can be created and placed on the VLAN interface for the 10.11.12.0 network:



              ip access-list 12 deny 10.11.13.0 0.0.0.255
              ip access-list 12 permit any
              !
              interface VLAN 12
               ip access-group 12 in
              !


              The direction (in or out) is from the perspective of the router, not the network.



              You could also create an ACL to place on the VLAN for the 10.11.13.0 network:



              ip access-list 13 deny 10.11.12.0 0.0.0.255
              ip access-list 13 permit any
              !
              interface VLAN 13
               ip access-group 13 out
              !





              share|improve this answer


























                up vote
                4
                down vote













                You can simply create access lists to restrict traffic, and place those access lists on the VLAN interfaces.



                For example an ACL to prevent traffic from 10.11.12.0/24 to 10.11.13.0/24 can be created and placed on the VLAN interface for the 10.11.12.0 network:



                ip access-list 12 deny 10.11.13.0 0.0.0.255
                ip access-list 12 permit any
                !
                interface VLAN 12
                 ip access-group 12 in
                !


                The direction (in or out) is from the perspective of the router, not the network.



                You could also create an ACL to place on the VLAN for the 10.11.13.0 network:



                ip access-list 13 deny 10.11.12.0 0.0.0.255
                ip access-list 13 permit any
                !
                interface VLAN 13
                 ip access-group 13 out
                !





                share|improve this answer
























                  up vote
                  4
                  down vote










                  up vote
                  4
                  down vote









                  You can simply create access lists to restrict traffic, and place those access lists on the VLAN interfaces.



                  For example an ACL to prevent traffic from 10.11.12.0/24 to 10.11.13.0/24 can be created and placed on the VLAN interface for the 10.11.12.0 network:



                  ip access-list 12 deny 10.11.13.0 0.0.0.255
                  ip access-list 12 permit any
                  !
                  interface VLAN 12
                   ip access-group 12 in
                  !


                  The direction (in or out) is from the perspective of the router, not the network.



                  You could also create an ACL to place on the VLAN for the 10.11.13.0 network:



                  ip access-list 13 deny 10.11.12.0 0.0.0.255
                  ip access-list 13 permit any
                  !
                  interface VLAN 13
                   ip access-group 13 out
                  !





                  share|improve this answer














                  You can simply create access lists to restrict traffic, and place those access lists on the VLAN interfaces.



                  For example an ACL to prevent traffic from 10.11.12.0/24 to 10.11.13.0/24 can be created and placed on the VLAN interface for the 10.11.12.0 network:



                  ip access-list 12 deny 10.11.13.0 0.0.0.255
                  ip access-list 12 permit any
                  !
                  interface VLAN 12
                   ip access-group 12 in
                  !


                  The direction (in or out) is from the perspective of the router, not the network.



                  You could also create an ACL to place on the VLAN for the 10.11.13.0 network:



                  ip access-list 13 deny 10.11.12.0 0.0.0.255
                  ip access-list 13 permit any
                  !
                  interface VLAN 13
                   ip access-group 13 out
                  !






                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited yesterday

























                  answered yesterday









                  Ron Maupin♦

                  56.2k94695




                  56.2k94695




















                      up vote
                      3
                      down vote













                      Hi and welcome to Network Engineering! We hope you will become a contributing member of this community.



                      The simplest way to do this is with access lists. They are essentially filters that can block specific source or destination addresses.



                      You could create an access list and apply it to Vlan A that only allows traffic to B, and blocks traffic to C and D.






                      share|improve this answer
























                        up vote
                        3
                        down vote













                        Hi and welcome to Network Engineering! We hope you will become a contributing member of this community.



                        The simplest way to do this is with access lists. They are essentially filters that can block specific source or destination addresses.



                        You could create an access list and apply it to Vlan A that only allows traffic to B, and blocks traffic to C and D.






                        share|improve this answer






















                          up vote
                          3
                          down vote










                          up vote
                          3
                          down vote









                          Hi and welcome to Network Engineering! We hope you will become a contributing member of this community.



                          The simplest way to do this is with access lists. They are essentially filters that can block specific source or destination addresses.



                          You could create an access list and apply it to Vlan A that only allows traffic to B, and blocks traffic to C and D.






                          share|improve this answer












                          Hi and welcome to Network Engineering! We hope you will become a contributing member of this community.



                          The simplest way to do this is with access lists. They are essentially filters that can block specific source or destination addresses.



                          You could create an access list and apply it to Vlan A that only allows traffic to B, and blocks traffic to C and D.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered yesterday









                          Ron Trunk

                          31.5k22667




                          31.5k22667




















                              user10021657 is a new contributor. Be nice, and check out our Code of Conduct.









                               

                              draft saved


                              draft discarded


















                              user10021657 is a new contributor. Be nice, and check out our Code of Conduct.












                              user10021657 is a new contributor. Be nice, and check out our Code of Conduct.











                              user10021657 is a new contributor. Be nice, and check out our Code of Conduct.













                               


                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function ()
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f53193%2fhow-not-to-route-on-a-cisco-router%23new-answer', 'question_page');

                              );

                              Post as a guest
































































                              Comments

                              Post a Comment

                              Popular posts from this blog

                              List of Gilmore Girls characters

                              Image
                              The season three cast—(Back row): Lane, Michel, Paris, Emily, Richard, Sookie, Miss Patty, Kirk; Front row: Jess, Luke, Lorelai, Rory, Dean This is a list of characters for the comedy-drama television series Gilmore Girls . Contents 1 Main characters 1.1 Lorelai Gilmore 1.2 Rory Gilmore 1.3 Sookie St. James 1.4 Lane Kim 1.5 Michel Gerard 1.6 Luke Danes 1.7 Emily Gilmore 1.8 Richard Gilmore 1.9 Paris Geller 1.10 Dean Forester 1.11 Jess Mariano 1.12 Kirk Gleason 1.13 Jason Stiles 1.14 Logan Huntzberger 2 Major recurring characters 2.1 Christopher Hayden 2.2 Jackson Belleville 2.3 Mrs. Kim 2.4 Tristin DuGray 2.5 Max Medina 2.6 Taylor Doose 2.7 Dave Rygalski 2.8 Marty 3 Recurring characters 3.1 Stars Hollow 3.2 Chilton 3.3 Yale 3.4 Other 4 Notable guest stars 5 Unseen characters 6 Notes 7 References Main characters Actor Character Appearances Season 1 Season 2 Season 3 Season 4 Season 5 Season 6 Season 7 A Year in the Life Lauren Graham Lorelai Gilmore...
                              Read more

                              What does second last employer means? [closed]

                              Image
                              Clash Royale CLAN TAG #URR8PPP .everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0; up vote -3 down vote favorite Say, for example I have worked in the following companies, Company A => 2010 - 2011 Company B => 2011 - 2012 Company C => 2012 - Till Date Company D => Have offer Now assume Company D is asking to submit documents from my second last employer. So from the list of companies given, which company would be qualified as second last employer? software-industry employer share | improve this question asked Aug 10 '14 at 5:16 Rajaprabhu Aravindasamy 559 1 6 13 closed as off-topic by Jim G., jmort253 ♦ Aug 11 '14 at 1:58 This question appears to be off-topic. The users who voted to close gave this specific reason: "Questions seeking advice on company-specific regulations, agreements, or policies should be directed to your manager or HR department. Questions that address...
                              Read more

                              One-line joke

                              A one-liner is a joke that is delivered in a single line. A good one-liner is said to be pithy - concise and meaningful. [1] Comedians and actors use this comedic method as part of their act, e.g. Jimmy Carr, Tommy Cooper, Rodney Dangerfield, Norm Macdonald, Ken Dodd, Stewart Francis, Zach Galifianakis, Mitch Hedberg, Anthony Jeselnik, Milton Jones, Shappi Khorsandi, Jay London, Mark Linn-Baker, Demetri Martin, Groucho Marx, Dan Mintz, Emo Philips, Tim Vine, Steven Wright and Henny Youngman and Arnold Schwarzenegger. [ citation needed ] Many fictional characters are also known to deliver one-liners, including James Bond, who usually includes pithy and laconic quips after disposing of a villain. [ citation needed ] Examples "A baby seal walks into a club." "A dyslexic man walks into a bra." (Anonymous) "There are three types of people, those who can count and those who can't." "Venison's dear, isn't it?" (Jimmy Carr) "An escala...
                              Read more