Solved

Blocking access from one VLAN to another on a Cisco 4503

Posted on 2004-09-28
10
720 Views
Last Modified: 2012-06-27
I need some help setting up an access list (or routing tables) on a Cisco 4503 with a Sup. IV board.  The switch is setup with 24 VLANs and I do not want 23 of the VLANs to be able to communicate with each other, only to the 24th VLAN.

I have included a rough diagram below.  Basically I want the 192.168.1.0 network to be able to communicate with the 192.168.0.0 network and the Internet, but not with the 192.168.2-23.0 networks.  The same for the rest of the networks.  The 192.168.0.0 network needs to be able to communicate with any of the networks.

My first idea was to setup up a deny access list on each Port-Channel (grouping two gig ports to each of the 2950's) for all traffic except for traffict to/from the 192.168.0.0 network, but it was not working.

Can anyone provide an example of what I need to do to make the happen?

Thanks,
Tom

                  Router to Internet
                        |
                        |
                  Router / Firewall
                  (192.168.0.254)
                        |
                        |
                  192.168.0.0/24 network
                        |
                        |

            Cisco 4503 (Sup. IV board running layer 3 routing)
                  -----------------------      
Cisco 2950T - 192.168.1.0/24 ---|||||||||||||||||||||||
Cisco 2950T - 192.168.2.0/24 ----||||||||||||||||||||||
Cisco 2950T - 192.168.3.0/24 -----|||||||||||||||||||||
Cisco 2950T - 192.168.4.0/24 ------||||||||||||||||||||
Cisco 2950T - 192.168.5.0/24 -------|||||||||||||||||||
Cisco 2950T - 192.168.6.0/24 --------||||||||||||||||||
Cisco 2950T - 192.168.7.0/24 ---------|||||||||||||||||
Cisco 2950T - 192.168.8.0/24 ----------||||||||||||||||
Cisco 2950T - 192.168.9.0/24 -----------|||||||||||||||
Cisco 2950T - 192.168.10.0/24 -----------||||||||||||||
Cisco 2950T - 192.168.11.0/24 ------------|||||||||||||
Cisco 2950T - 192.168.12.0/24 -------------||||||||||||
Cisco 2950T - 192.168.13.0/24 --------------|||||||||||
Cisco 2950T - 192.168.14.0/24 ---------------||||||||||
Cisco 2950T - 192.168.15.0/24 ----------------|||||||||
Cisco 2950T - 192.168.16.0/24 -----------------||||||||
Cisco 2950T - 192.168.17.0/24 ------------------|||||||
Cisco 2950T - 192.168.18.0/24 -------------------||||||
Cisco 2950T - 192.168.19.0/24 --------------------|||||
Cisco 2950T - 192.168.20.0/24 ---------------------||||
Cisco 2950T - 192.168.21.0/24 ----------------------|||
Cisco 2950T - 192.168.22.0/24 -----------------------||
Cisco 2950T - 192.168.23.0/24 ------------------------|

0
Comment
Question by:TUmphress
  • 5
  • 4
10 Comments
 
LVL 43

Expert Comment

by:JFrederick29
ID: 12174401
The access-lists need to reside on the VLAN interfaces on the 4503, not the individual ports.
0
 
LVL 4

Expert Comment

by:celsmk
ID: 12178603
Hi,

Create the following access-list:
!
! permit access from 192.168.0.0 /24 network
access-list 100 permit ip 192.168.0.0 0.0.0.255 any
!
! deny access from any other 192.168.0.0/16 network
access-list 100 deny ip 192.168.0.0 0.0.255.255 any
!
! permit access fro any other network
access-list 100 permit any any
!

Then apply this access-list on each VLAN interface as an inbound filter:
!
interface xxxx
 ip access-group 100 in
!

regards,

celsmk
0
 

Author Comment

by:TUmphress
ID: 12180012
Celsmk,

Your suggestion is what I had tried in the past, BUT I did try it again last night and was able to get it to work.

The wierd thing is that at first it did not work again.  I was able to ping between networks.  I then removed the 'permit any any' line and it blocked as it should, but you were not able to get to the Internet, again as expected.  I then re-added the 'permit any any' line and all is working as expected now.  It does not make sense to me.  It was as if it was ignoring the match on the 'deny' line and continuing down through the access list.

The only difference between what I did and what you suggest is that I applied it as an 'out' on the interface.  My understanding is that the 'out' is out of the switch port and 'in' is into the switch port.  Is that correct?    If I put it on the 'in' it would seem to me that I would have to switch the lines around to be something like 'deny ip any 192.168.0.0 0.0.255.255'.  It seems that it would make more sense to put it on the 'in' so that the traffice, conceptually, did not get into the switch, did not bother to get routed and then blocked.  Please let me know your thoughts and thank you for the reply.

-Tom
0
 
LVL 4

Expert Comment

by:celsmk
ID: 12182202
TUmhress,

The access-list as I wrote should be applied inbound. Please note:

access-list 100 permit ip 192.168.0.0 0.0.0.255 any
                                                                     ---
                                                                     destination address
                                    -------------------------
                                    source address

Where did you apply to the ACL? You should have it applied to all VLAN interfaces (NOT on physical interfaces) but the VLAN interface assigned to subnet 192.168.0.0/24 as following:

access-list 100 permit ip 192.168.0.0 0.0.0.255 any
deny access from any other 192.168.0.0/16 network
access-list 100 deny ip 192.168.0.0 0.0.255.255 any
access-list 100 permit ip any any
!
interface VLAN x
 ip address 192.168.0.x 255.255.255.0
! no access-group here!
!
interface VLAN a
 ip address 192.168.1.x 255.255.255.0
 access-group 100 in
!
interface VLAN b
 ip address 192.168.2.x 255.255.255.0
 access-group 100 in
!
interface VLAN c
 ip address 192.168.3.x 255.255.255.0
 access-group 100 in
!
....and so on.

0
 
LVL 4

Expert Comment

by:celsmk
ID: 12183239
Sorry, wrong commands in my previous answer. The correct configurations are:
!
access-list 100 permit ip 192.168.0.0 0.0.0.255 any
access-list 100 deny ip 192.168.0.0 0.0.255.255 any
access-list 100 permit ip any any
!
interface VLAN x
 ip address 192.168.0.x 255.255.255.0
! no ip access-group here!
!
interface VLAN a
 ip address 192.168.1.x 255.255.255.0
 ip access-group 100 in
!
interface VLAN b
 ip address 192.168.2.x 255.255.255.0
 ip access-group 100 in
!
interface VLAN c
 ip address 192.168.3.x 255.255.255.0
 ip access-group 100 in
!
....and so on.
0
Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 

Author Comment

by:TUmphress
ID: 12183296
Celsmk,

I may have mis-spoken when I said that I was using VLANs.

Here is an example of the configuration:
<snip>
port-channel load-balance src-ip
!
!
interface Port-channel10
 ip address 192.168.10.254 255.255.255.0
 ip access-group ClsBlock out
 ip helper-address 192.168.0.107
!
interface Port-channel11
 ip address 192.168.11.254 255.255.255.0
 ip access-group ClsBlock out
 ip helper-address 192.168.0.107
</snip>
<snip>
interface GigabitEthernet2/19
 no switchport
 no ip address
 channel-group 10 mode active
!
interface GigabitEthernet2/20
 no switchport
 no ip address
 channel-group 10 mode active
!
interface GigabitEthernet2/21
 no switchport
 no ip address
 channel-group 11 mode active
!
interface GigabitEthernet2/22
 no switchport
 no ip address
 channel-group 11 mode active
</snip>
<snip>
ip default-gateway 192.169.0.254
ip classless
no ip forward-protocol udp bootpc
no ip forward-protocol udp tftp
no ip forward-protocol udp domain
no ip forward-protocol udp time
no ip forward-protocol udp netbios-ns
no ip forward-protocol udp netbios-dgm
no ip forward-protocol udp tacacs
ip route 0.0.0.0 0.0.0.0 192.168.0.254
!
!
ip access-list extended ClsBlock
 permit ip 192.168.0.0 0.0.0.255 any
 deny   ip 192.168.0.0 0.0.255.255 any
 permit ip any any
</snip>

I do like the idea of blocking on the inbound versus the outbound.  Does the above information change anything?

It is working now, but I would like it configured in the most optimal way, so I am open to changes.

Thanks again,
Tom
0
 
LVL 4

Accepted Solution

by:
celsmk earned 125 total points
ID: 12183832
Tom,

Here is a snip from Cisco IOS Manual:
<snip>
For inbound access lists, after receiving a packet, the Cisco IOS software checks the source address of the packet against the access list. If the access list permits the address, the software continues to process the packet. If the access list rejects the address, the software discards the packet and returns an ICMP host unreachable message.

For outbound access lists, after receiving and routing a packet to a controlled interface, the software checks the source address of the packet against the access list. If the access list permits the address, the software sends the packet. If the access list rejects the address, the software discards the packet and returns an ICMP host unreachable message.
</snip>

Therefore, using input filtering is better, because you do not need to route the packet before deciding if packet should be dropped.

I would suggest the following configuration:
!
interface Port-channel10
 ip address 192.168.10.254 255.255.255.0
 ip access-group ClsBlock_mod in
!
interface Port-channel11
 ip address 192.168.11.254 255.255.255.0
 ip access-group ClsBlock_mod in
!
!
ip access-list extended ClsBlock_mod
 permit ip any 192.168.0.0 0.0.0.255
 deny   ip any 192.168.0.0 0.0.255.255
 permit ip any any
!

Did you try this before?

Regards,

Celsmk
0
 

Author Comment

by:TUmphress
ID: 12183977
I thought I had, but I could have just had a stupid typo.  I will try this method and post the results, it looks like it would work to me.  I may not be albe to get to it until tomorrow.

The points are yours though.  Thank you for working through this with me.  I think the delay or odd ballness in the appling was throwing me off.  As I thought that I understood access list.  But, one can always learn more.  :)

-Tom
0
 
LVL 4

Expert Comment

by:celsmk
ID: 12184295
Hope it will work ok for you.
Tks a lot!

Celsmk
0
 

Author Comment

by:TUmphress
ID: 12220896
Celsmk,
I implemented the suggestion above and all is working well.  Thanks again for your assistance.

-Tom
0

Featured Post

Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

Join & Write a Comment

Suggested Solutions

It happens many times that access list (ACL) have to be applied to outgoing router interface in order to limit some traffic.This article is about how to test ACL from the router which is not very intuitive for everyone. Below scenario shows simple s…
Getting hacked is no longer a matter or "if you get hacked" — the 2016 cyber threat landscape is now titled "when you get hacked." When it happens — will you be proactive, or reactive?
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

707 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now