vLAN configuration issues

Answered Question

Good day everyone,


I'm rather stuck configuring ACLs in our environment. Allow me to explain in detail:


Our organisation is divided into 4 virtual LANs:


192.168.0.0/23 (This is our live network, all our employees are using this network)

192.168.4.0/24 (This vLAN is used for testing purposes)

192.168.5.0/24 (This vLAN is used for demonstrational purposes)

192.168.6.0/24 (This vLAN is used by external parties)


Right now I'm trying to configure ACLs for the 192.168.5.0/24 network. This network contains a domain controller (192.168.5.10) which needs access to the domain controller/internet router in our live environment (the address for this domain controller is 192.168.0.210) in order to get internet working on this vLAN. The exact problem is: Whenever I disable all the ACLs, everything works like a charm, but whenever I implement the ACLs, internet access seems to stop functioning. I'll write down the contents of the ACLs for you. ACL 150 is applied to the outbound interface of the gateway (gateway=192.168.5.1, which is a 2811), and ACL 151 is applied to the inbound interface:


Extended IP access list 150
    10 permit ip 192.168.0.0 0.0.1.255 192.168.5.0 0.0.0.255
Extended IP access list 151
    10 permit tcp 192.168.5.0 0.0.0.255 192.168.0.0 0.0.1.255 established
    20 permit tcp host 192.168.5.10 host 192.168.0.210 eq domain
    30 permit tcp host 192.168.5.10 host 192.168.0.210 eq www
    40 permit icmp 192.168.5.0 0.0.0.255 192.168.0.0 0.0.1.255 echo-reply


I can seem to ping the DC in the live environment ok, and I can even resolve IP addresses, but somehow I just can't seem to connect to them. I even tried using the "permit ip host 192.168.5.10 any", but I still haven't got it to work. Could someone please provide me with some assistance? It'd be greatly appreciated. Thank you very much in advance.


Best regards,


Chris

Correct Answer by Jon Marshall about 7 years 1 month ago

Chris


Perhaps an interesting note, when executing a tracert command when the ACLs are applied, the requests time out after they reach the DC (it seems to get blocked after that).


It will be blocked because your outbound acl only allows source addresses from 192.168.0.0/23 back in. As for internet access this is the same problem if you are not using a proxy server with a 192.168.0.x address ie. all the source addresses coming back into the 192.168.5.x vlan will be blocked by your outbound acl ie. acl 150.


Jon

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Collin Clark Fri, 04/09/2010 - 08:12
User Badges:
  • Purple, 4500 points or more

Chris-


Is this ACL exactly what you have in place (check the area in red)?


Extended IP access list 150
    10 permit ip 192.168.0.0 0.0.1.255  192.168.5.0 0.0.0.255

Jon Marshall Sun, 04/11/2010 - 23:58
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Chris


ACL 150 is applied to the outbound interface of the gateway (gateway=192.168.5.1, which is a 2811), and ACL 151 is applied to the inbound interface:


Could you clarify what you mean by the above. Are the 2 acls applied to the same interface or different interfaces ?


Jon

Jon Marshall Mon, 04/12/2010 - 00:50
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Chris


That's what is confusing. You wrote -


I can seem to ping the DC in the live environment ok


but your inbound acl does not permit that. It allows echo-reply but not echo-request ie.


Extended IP access list 151
    10 permit tcp 192.168.5.0 0.0.0.255 192.168.0.0 0.0.1.255 established
    20 permit tcp host 192.168.5.10 host 192.168.0.210 eq domain
    30 permit tcp host 192.168.5.10 host 192.168.0.210 eq www
    40 permit icmp 192.168.5.0 0.0.0.255 192.168.0.0 0.0.1.255 echo-reply


if acl 151 is applied inbound then this will affect traffic coming from clients on that vlan. So if you try and ping from a client on that vlan to the DC in production it should fail because of the implicit deny at the end of every acl. So it's definitely confusing.


Are you sure that -


1) acl 151 is applied inbound

2) you can ping the DC from a device on the 192.168.5.x vlan


Jon


Jon,


1) Yes, I'm sure. I just checked the config.

2) Well yes, but I forgot to explain something:


You're absolutely right; I shouldn't be able to ping the DC.


What I forgot to mention was that I (because I didn't get the ACLs to work), added a line to the inbound ACL:


"permit ip host 192.168.5.10 any". I figured that by giving one host unlimited access to our internal domain, no traffic should be blocked (this was just for testing purposes). I just tried it again, but even though it can resolve domain names just fine, I just can't seem to get a ping reply.


Perhaps an interesting note, when executing a tracert command when the ACLs are applied, the requests time out after they reach the DC (it seems to get blocked after that). That would lead me to believe to problem isn't the router. However, when I execute the same command after the ACLs are disabled, it forwards the request just fine to our ISP and I get an echo-reply. Which is weird, because I believe I granted the host unrestricted access to the network.


I'm stumped..


Chris

Correct Answer
Jon Marshall Mon, 04/12/2010 - 01:17
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Chris


Perhaps an interesting note, when executing a tracert command when the ACLs are applied, the requests time out after they reach the DC (it seems to get blocked after that).


It will be blocked because your outbound acl only allows source addresses from 192.168.0.0/23 back in. As for internet access this is the same problem if you are not using a proxy server with a 192.168.0.x address ie. all the source addresses coming back into the 192.168.5.x vlan will be blocked by your outbound acl ie. acl 150.


Jon

Jon,


I've adjusted the ACL accordingly, and it seems to work perfectly now. I guess my mistake was assuming that all the internet traffic would be labeled as traffic originating from 192.168.0.0/23, which it's not. I guess I'll be using - as you suggested - a proxy server as a workaround.


At any rate, I'd like to thank you (and the other replies) very much for all the assistance; it's greatly appreciated and you might've saved my hide


Best regards,


Chris

Actions

This Discussion