Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Vlan Racl question

Hello -

My IT department will be supporting a seperate company, but will be riding on our backbone. i am segmenting their network traffic using RACLs and placing them on their respective VLANs that I have created for them. I am creating a VPN tunnel so they can connect back to their netowrk resources at their head offcie. It just happens that the IP range for their head office, falls into class B that we are using at our location. I entered a more specific ACE for the ACL but for some reason it is hitting a deny statement as opposed to the permit statement the line above. Any reason for this?

Notice where the match statements are occuring when I attemt to ping a device destined to the other company's head office.

10 permit ip 10.50.162.0 0.0.0.255 172.20.4.0 0.0.3.255

20 deny ip 10.50.162.0 0.0.0.255 172.20.0.0 0.0.255.255 (3 matches)

30 deny ip 10.50.162.0 0.0.0.255 172.33.0.0 0.0.255.255

40 deny ip 10.50.162.0 0.0.0.255 172.34.0.0 0.0.255.255

50 deny ip 10.50.162.0 0.0.0.255 172.35.0.0 0.0.255.255

60 deny ip 10.50.162.0 0.0.0.255 172.36.0.0 0.0.255.255

70 deny ip 10.50.162.0 0.0.0.255 172.37.0.0 0.0.255.255

80 deny ip 10.50.162.0 0.0.0.255 172.38.0.0 0.0.255.255

90 deny ip 10.50.162.0 0.0.0.255 172.39.0.0 0.0.255.255

100 deny ip 10.50.162.0 0.0.0.255 172.40.0.0 0.0.255.255

110 deny ip 10.50.162.0 0.0.0.255 172.41.0.0 0.0.255.255

120 deny ip 10.50.162.0 0.0.0.255 172.42.0.0 0.0.255.255

130 deny ip 10.50.162.0 0.0.0.255 172.90.0.0 0.0.255.255

140 deny ip 10.50.162.0 0.0.0.255 10.50.100.0 0.0.3.255

150 deny ip 10.50.162.0 0.0.0.255 10.50.152.0 0.0.3.255

160 deny ip 10.50.162.0 0.0.0.255 10.50.156.0 0.0.3.255

170 deny ip 10.50.162.0 0.0.0.255 192.168.6.0 0.0.0.255

180 deny ip 10.50.162.0 0.0.0.255 192.168.1.0 0.0.0.255

190 deny ip 10.50.162.0 0.0.0.255 192.168.2.0 0.0.0.255

200 deny ip 10.50.162.0 0.0.0.255 192.168.3.0 0.0.0.255

210 deny ip 10.50.162.0 0.0.0.255 10.50.64.0 0.0.0.255

220 deny ip 10.50.162.0 0.0.0.255 10.49.19.0 0.0.0.255

7 REPLIES
Blue

Re: Vlan Racl question

it would be nice to have the source/destination addresses that are attempting to communicate and what protocol/port.

also, the config that shows the VACLs and how they're implemented (what vlans, etc)

New Member

Re: Vlan Racl question

Thanks for responding....

the ICMP packet matches the top ACE in the pasted RACL

Source address - 10.50.162.250

Dest address - 172.20.4.10

It is applied to the VLAN I created (in this case 162) that this traffic is originating from. I am more interested in why the ICMP packet is not hitting the first ACE on the ACL.

Blue

Re: Vlan Racl question

may sound mundane but please provide the subnet masks you have configured for hosts:

10.50.162.250

172.20.4.10

thank you.

New Member

Re: Vlan Racl question

Mask for the source host is /24

Mask for the destination host should not be an issue, since I can define ranges in ACLs anyway I choose, as long as they are valid ranges, but I am assuming they are 4 seperate /24s as well. These a the 4 remote networks, but this would be a logical assumption.

The remote network I was provided for the seperate company was .4.0 - .7.0 matching my 3.255 wildcard mask in the ACE.

Just to demonstrate that moving to 4 seperate lines in the ACL makes no difference in this problem I have included the change.

Extended IP access list RC162

10 permit ip 10.50.162.0 0.0.0.255 172.20.4.0 0.0.0.255

20 permit ip 10.50.162.0 0.0.0.255 172.20.5.0 0.0.0.255

30 permit ip 10.50.162.0 0.0.0.255 172.20.6.0 0.0.0.255

40 permit ip 10.50.162.0 0.0.0.255 172.20.7.0 0.0.0.255

50 deny ip 10.50.162.0 0.0.0.255 172.20.0.0 0.0.255.255 (3 matches)

60 deny ip 10.50.162.0 0.0.0.255 172.33.0.0 0.0.255.255

70 deny ip 10.50.162.0 0.0.0.255 172.34.0.0 0.0.255.255

80 deny ip 10.50.162.0 0.0.0.255 172.35.0.0 0.0.255.255

90 deny ip 10.50.162.0 0.0.0.255 172.36.0.0 0.0.255.255

100 deny ip 10.50.162.0 0.0.0.255 172.37.0.0 0.0.255.255

110 deny ip 10.50.162.0 0.0.0.255 172.38.0.0 0.0.255.255

120 deny ip 10.50.162.0 0.0.0.255 172.39.0.0 0.0.255.255

130 deny ip 10.50.162.0 0.0.0.255 172.40.0.0 0.0.255.255

140 deny ip 10.50.162.0 0.0.0.255 172.41.0.0 0.0.255.255

150 deny ip 10.50.162.0 0.0.0.255 172.42.0.0 0.0.255.255

160 deny ip 10.50.162.0 0.0.0.255 172.90.0.0 0.0.255.255

170 deny ip 10.50.162.0 0.0.0.255 10.50.100.0 0.0.3.255 (3 matches)

180 deny ip 10.50.162.0 0.0.0.255 10.50.152.0 0.0.3.255

190 deny ip 10.50.162.0 0.0.0.255 10.50.156.0 0.0.3.255

200 deny ip 10.50.162.0 0.0.0.255 192.168.6.0 0.0.0.255

210 deny ip 10.50.162.0 0.0.0.255 192.168.1.0 0.0.0.255

220 deny ip 10.50.162.0 0.0.0.255 192.168.2.0 0.0.0.255

230 deny ip 10.50.162.0 0.0.0.255 192.168.3.0 0.0.0.255

240 deny ip 10.50.162.0 0.0.0.255 10.50.64.0 0.0.0.255

250 deny ip 10.50.162.0 0.0.0.255 10.49.19.0 0.0.0.255

260 permit ip 10.50.162.0 0.0.0.255 any (154 matches)

Blue

Re: Vlan Racl question

.

Blue

Re: Vlan Racl question

looks like your first rule, 10, may not be correct.

this rule allows IP from 10.50.162.0/24 to 172.20.4.1 - 172.20.7.254.

although these ranges do seem correct as they are written, try to change the first rule to 172.20.4.0 0.0.0.255 for a test. if the test then works, you'll probably be able to find a routing issue somewhere in your environment that causes the 172.20.40.0 0.0.3.255 to be a problem. (do you really have your 172 subnetted this way? if not, then we may have to look further at the routing)

New Member

Re: Vlan Racl question

The address scheme that you see in these ACLs are in fact the way it is designed. That was done probably 8 years ago, by an engineer, who probably wan't that expierenced (as you notice there a handful of public ranges that we are using in private space). That is a project for another day though.

The routing issue you mentioned doesn't seem to be the culprit though. I can remove the deny 172.20 ACE and the packets gets routed fine to its end destination over the IPSEC tunnel.

I might end up getting rid of our 172.20 network sooner than later if I can't figure out a solution to this issue. There isn't much left on that subnet anyways, just a bunch of legacy servers, and so radius boxes.

142
Views
0
Helpful
7
Replies
CreatePlease to create content