Trouble setting up VLANs and reaching the outside world

[Spork Schivago]

Hi!   I have a Cisco C1111-8PW running 16.06.05 and I am trying to setup an extra VLAN for the first time.   My current setup is like this:

Static Public IP on GigabitEthernet 0/0/1

VLAN1 on network 10.0.0.0 / 24

VLAN40 on network 10.0.40.0 / 24

The issue that I would like to deal with is that I can ping the 10.0.0.0 network from the 10.0.40.0 network and vice-versa.   I want them isolated.   I believe inter-VLAN routing is what is currently turned on, and I am not certain how to turn that off.

If anyone else sees something wrong or thinks I could do something better with my running-config, please do not hesitate to mention it!

Thanks!

[houtan haddadlarijani · Accepted solution]

Hi,

All you need is an inbound access-list on either vlan 1 or vlan 40 to block the connection between these 2 subnets.

For example:

access-list 101 deny ip 10.0.0.0 0.0.0.255 10.0.40.0 0.0.0.255
access-list 101 permit ip any any

!

int vlan 1

ip access-group 101 in

HTH

[Spork Schivago]

---

@houtan haddadlarijani wrote:

Hi,

All you need is an inbound access-list on either vlan 1 or vlan 40 to block the connection between these 2 subnets.

Thank you!

---

@houtan haddadlarijani

For example:

access-list 101 deny ip 10.0.0.0 0.0.0.255 10.0.40.0 0.0.0.255
access-list 101 permit ip any any

!

Could you help me understand this a little bit more? The way I understand it is: It's a standard access-list, with rule number 101. We are denying access to the 10.0.40.0 / 24 network if the source address is from the 10.0.0.0 / 24 network. I think I understand the 101 part.   At first, I was confused how two access lists could share the same rule number.   But I think I understand now.   101 is the group-name, and then we have two rules added to that group.   Is that correct?

  Also, with the permit ip any any access-list...Is there a way to do a deny ip any any access-list but before that, allow those networks to accept incoming / outgoing PATted traffic?   The only reason I ask, I have the management port out-of-band, but I am always worried someone might gain access to it by me not setting these access-lists up correctly.

Finally, if I wanted to allow traffic from 10.0.0.5 / 24 host to 10.0.40.7 host, would this be the proper command? access-list 101 permit host 10.0.0.5 host 10.0.40.7 eq ?

access-list 101 deny ip 10.0.0.0 0.0.0.255 10.0.40.0 0.0.0.255

access-list 101 permit ip any any

---

@houtan haddadlarijani

int vlan 1

ip access-group 101 in

HTH

---

 I think once I verify this solves the problem (and I truly believe the commands you shared will solve my issue), I think I am going to try working on setting up the other VLANs.  I like the ability to name the access-lists, because it's easier for me to remember what I was trying to do or why they exist.   I don't think I can do that with standard access-lists, but I know how with extended.   I name the VLANs something that helps me remember as well.   I believe there's a few other small things I need to setup.   Right now, I can access the management ports on the router and WLC and AP, regradless of what my IP address.   I want to lock that down, so only a certain IP can access them.   I'll probably look into the DHCP server stuff a bit more, see if I can get the DHCP server to hand out a specific IP based on the devices MAC address.

Thank you for the help!   From my internet searches, it originally sounded like I was going to have to use access maps and the examples I saw confused me a little.   I didn't fully understand them, and your way is nice and clear.   I will have more VLANs that I still need to setup, but I do not expect to have to change anything drastically.   I think I can easily modify the 101 access-list you shared and do the same for the other networks / VLANs I will be blocking from the inter-VLAN routing.

[Spork Schivago]

**EDIT:

I thought I was doing something wrong, because from the router itself, I could ping the various VLANs from the various VLANs.   For example, ping 10.0.0.1 source vlan 40   will succeed.    However, once I connect to the actual network and use a host device, I cannot.

Is there a way to prevent the pings from working from the Cisco console as well?   So ping 10.0.0.1 source vlan 40  will fail?

Here's my current access-lists:

Standard IP access list NAT_TRANSLATIONS
    10 permit 10.0.0.0, wildcard bits 0.0.0.255
    20 permit 10.0.40.0, wildcard bits 0.0.0.255
Extended IP access list 100
    10 permit udp any any eq bootpc
Extended IP access list BLOCK_INTERVLAN_ROUTING
    10 deny ip 10.0.0.0 0.0.0.255 10.0.40.0 0.0.0.255 (4 matches)
    20 deny icmp 10.0.0.0 0.0.0.255 10.0.40.0 0.0.0.255
    100 permit ip any any (2479 matches)
Extended IP access list NO_OUTFACING_SERVICES
    10 deny tcp any any eq telnet (3 matches)
    20 deny tcp any any eq 22 (342 matches)
    30 deny tcp any any eq www (1 match)
    40 deny tcp any any eq 443
    50 deny tcp any any eq finger
    60 deny tcp any any eq cmd
    100 permit ip any any (11504 matches)
Extended IP access list NO_WEBCONFIG_SERVICES
    10 deny tcp any any eq www (526 matches)
    20 deny tcp any any eq 443 (168 matches)
    30 permit ip any any (16776015 matches)
Extended IP access list sl_def_acl
    10 deny tcp any any eq telnet
    20 deny tcp any any eq www
    30 deny tcp any any eq 22
    40 permit ip any any

In the running-config, I do see a couple things that worry me.   These in particular:

ip nat inside source route-map track-primary-if interface GigabitEthernet0/0/1 overload
ip access-list match-local-traffic
!
route-map track-primary-if permit 1
match ip address 197
set interface GigabitEthernet0/0/1
!

I am not sure if this was something I did a while back when I was trying to get NAT working, and just forgot to remove it, or where it actually came from and what it exactly does.   I think the match ip address is trying to match to rule 197, which doesn't exist, as far as I can tell.   Not sure what the match-local-traffic is doing.   I'm wondering if it's safe if I remove those entries I just posted there...I'm trying to figure out what they mean but google hasn't been much help with the searching for the 197 thing.

Thanks!!!!

[Alan Ng'ethe]

I have simulated this problem and come to the conclusion that what @houtan haddadlarijani posted works, at least in my simulation which closely resembles your setup. And one of the observations I have made is that the acl will not filter traffic originating from the router itself, and that is why you are able to ping vlan 1 with a source of vlan 40.

That is the only reasonable conclusion I can come to regarding this phenomenon.

And now I will share my observations;

A ping from the router sourced on vlan1 interface to vlan 10 interface

A ping from the router sourced on vlan1 interface to a host inside vlan 10 interface

However, a ping from the host in vlan10 to a host in vlan 1

  

And the reverse is also true for a ping sourced from a host in vlan 10 to a host in vlan1.

Switching back to the router confirms this; that the acl 110 is working as expected, and that the acls 50 and 60 which allow translations out to the internet also do what they are supposed to.

R1#sh access-lists 110
Extended IP access list 110
10 deny ip 10.0.0.0 0.0.0.255 10.0.40.0 0.0.0.255 log (20 matches)
20 permit ip any any (22 matches)

R1#

*Mar 1 00:53:00.843: %SEC-6-IPACCESSLOGDP: list 110 denied icmp 10.0.0.10 -> 10.0.40.10 (0/0), 5 packets

R1#sh ip nat translations
Pro Inside global               Inside local             Outside local    Outside global
udp 41.215.139.53:54112 10.0.40.10:54112 8.8.8.8:54113 8.8.8.8:54113

For starters, I would suggest reapplying the ACL 110, and then testing from hosts inside their respective vlans.

[Spork Schivago]

@Alan Ng'ethe,

I came to the same conclusion as you and thought I had posted that, but things where a little hectic around here the other night, and I might had forgotten.   Sorry to have you go through all the work there to test what I had tested.   I was thinking being able to ping the various VLANs from the router itself is probably a good thing to have, for various testing purposes.   I am going to accept the persons solution as the correct answer.

I was reading an article on setting something else up on a Cisco device (it was an article on a Cisco site) and in this article, they only used the GUI, not the CLI, however, when they created the VLANs, there was a checkbox to disable inter-VLAN routing.   It would be nice if I could find out if disabling it is an option, rather than adding a little overhead blocking it using ACLs.

I do have one more issue related to VLANs and feel that this is probably the best place to ask.   So I don't want to close the thread yet.   Thanks!

[Alan Ng'ethe]

Please ignore my post above, I had a draft open as I ran the simulation, but see we have come to the same conclusion. Also, regarding your last post, as you say I, do not see any acls by the names '97' and 'match-local-traffic', so it should be safe to ignore those configurations or remove them at some point in order to sanitize your router configurations.

On pings originating from the router console, I would probably look into Control Plane Policing, but at this moment I am not sure whether that is the solution. Either way, I would say that traffic originating from the router *shouldn't* constitute a security risk, and in fact can be handy when it comes to troubleshooting.

Even if there was a way to filter it I would leave that turned on.

[Spork Schivago]

@Alan Ng'ethe,

It seems we think alike!   As you was typing that, I posted how I think it's more beneficial to leave it open for testing purposes / troubleshooting later on.   I didn't plan on disabling it, I wanted to try and understand why.   I think I know though.   I have a console connection, and I think that might have something to do with it.   I figure when I supply a source address or interface name for ping, the IOS injects that IP address into the packet header there.   But maybe it figures if I'm on the router's console port, I probably don't want ACLs to apply.   If they did, maybe it could even break some of the IOS features.   I'm not sure.

So, I still have a VLAN issue and thought it was related enough to keep it in this thread, but maybe it's best to move it to a new thread.   Anyways, here goes.   So, now I have my two VLANs and two SSIDs properly working.   VLAN1 (MyBusiness), which is the default VLAN, and VLAN40 (Guests) which is for guests.   There's the two SSIDs, MyBusiness, and MyBusiness Guests.   There are devices that will be connecting via wireless and I don't feel like they really belong to either of those two categories.   For example, our TV set top boxes use ethernet for their source.   I want TV to be segregated from the business stuff and from the guest stuff.   There's also what I call IoT devices, like our car, and the garage door opener.   Finally, game consoles.   I think they should be isolated as well.

I am trying to find a way to do this without creating more wireless SSIDs.   I think private-VLANs is what I want...would that be correct?   I feel I have a much more indepth understanding of VLANs, but the document on reading on Private-VLANs don't clear everything up for me.   Are Private-VLANs something that I should use?   That way, the gaming consoles can be on a private-VLAN and maybe communicate with each other, and then car and garage door opener will be on another VLAN but they cannot communicate with the gaming consoles, the DC's stuff, like the PDUs management port, and the HPEs management port, I feel they should be on a seperate VLAN all together.   But then the previous devices I just talked about could all be on the same network, just in private-VLANs and not communicate with each other at all.  Is there a better way to do this or am I thinking the right way?

Thanks!

[Alan Ng'ethe]

Hi @Spork Schivago,

Thanks for the ratings!

Regarding your question, i want to suggest that you open a fresh thread so that your question may be more visible by the other more experienced members of the community.

[Spork Schivago]

Okay, I will start a new thread. Thanks for all the help guys!