04-09-2010 08:04 AM - edited 03-06-2019 10:32 AM
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
Solved! Go to Solution.
04-12-2010 01:17 AM
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
04-09-2010 08:12 AM
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
04-11-2010 11:46 PM
Hello Collin,
Thanks for the reply! It is indeed correct, one of the previous administrators had migrated the network to the 192.168.0.0 255.255.254.0 range for some extra space. Do you have any ideas why it isn't working?
Thanks again,
Chris
04-11-2010 11:58 PM
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
04-12-2010 12:35 AM
04-12-2010 12:50 AM
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
04-12-2010 01:09 AM
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
04-12-2010 01:17 AM
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
04-12-2010 01:52 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide