Access List help

[IllegalOperation]

I just created the following access list on a 1721 router, and enabled it on its serial WAN interface....

ip access-list extended test
permit tcp any any established
permit ip any 192.168.50.0 0.0.0.3
permit ip any host x.x.x.x


What I want it to do is to allow packets that are only requested from inside the 1721 to pass through (established rule), allow packets from that 192.168.50.0 subnet to pass through, and to allow access from a different router located at a remote site (with a registered IP address of x.x.x.x).

Unfortunately, the third rule is not working at all. As soon as I enable this access list on the 1721's interface, I can no longer telnet/ping to that router with the "x.x.x.x" router. They communicate fine when the access list is disabled. Is there something that I am missing that will let me have the two routers communicate when the access list is enabled?

 

[l1carter]

just a suggestion for debugging access-lists. add the key work log at the end of your permit statements. That way when you try to telnet to the remote host end you should see a console message saying that you were permitted access. If you don't and your access-list logs stay empty then there is something missing like incorrect host address or something.

 

[IllegalOperation]

Well the problem with that is when the access list is enabled, I can not even get access to the 1721 router remotely (so I cant see any of the logs). It is blocking the router with the x.x.x.x out for some reason. I do not understand why I cant gain access, as I am simply permitting this specific x.x.x.x address to pass through.

By the way, if anyone asks I added the access list to the inbound of the serial interface.

 

[IllegalOperation]

Nevermind, I figured it out. I had the host and the destination parameters backwards. I actually thought the destination came first.

My access list looks ready to go, with the exception that everyone behind the router is now blocked from accessing the internet.

I thought that the "permit tcp any any established" command would allow internet access, but apparently not. I am assuming I will need to open up port 80 for my LAN subnet?

permit tcp any 192.168.0.0 0.0.0.255 eq www

Is that right? I hope not, because that is not working right now. How do I enable internet access through my ACL for my LAN?

 

[ChrisAC]

Allowing access from the internet to 192.168.0.0 /24 won't work as packets will not be directed to this address range. This is a private RFC1918 address range.

Chris.


**********************
Chris Andrew, CCNA, CCSA
chris@iproute.co.uk
**********************

 

[IllegalOperation]

I understand that iproute. I am using NAT, and is working quite well. We are surfing the web very happily, until I enable my access list. I just would like to know what I need to enter in my access list to enable internet traffic to pass through the WAN interface of my router.

Internet traffic: HTTP, HTTPS, perhaps even PING

 

[bierhunter]

Well, after reading through, I think I've gotten myself confused as to which direction your access list is configured for, so I'm going to through out some ideas that I hope will help.

I'm assuming you only have a single public address issued to you from your provider.

Note: With NAT, an outgoing request automatically opens a return path (for that session). Otherwise, inbound paths are closed. You don't really need the established access-list entry.

1. Are you hosting any services on your private network that need access from the outside (web, email, DNS, etc).

For example: Say you have an internal web server you want to access from the Internet with an IP of 192.168.0.5 and your public address is 205.193.24.30 (Just for this example...I just made up the public address).

Add this line:
ip nat inside source {static {tcp | udp local-ip local-port global-ip global-port} [extendable]

example for a web server:
ip nat inside source static tcp 192.168.0.5 80 205.193.24.30 80 extendable

That will forward port 80 traffic to the designated private address. Remember, outside clients can only talk to your public address.
For telnet:
ip nat inside source static tcp 192.168.0.5 23 205.193.24.30 23 extendable

Ok...now...for the inbound access list, only use the public address and not the private addresses.
(for telnet)
access-list 120 permit tcp <source> <destination> eq 23

Remember that there is always an implied &quot;deny all&quot; at the end of the access list. And, the lines are processed in order until a match is found.

I hope that helps. There's more; but naturally, I can't go into everything.

http://www.cisco.com

has a great search box. Just enter ACL or NAT or whatever, and you'll get a ton of examples.

Good luck.

 

[IllegalOperation]

Thanks bierhunter for the great info. You are correct, I only have one public ip that I am using. I actually have one question left...


I want to have an access list that pretty much blocks the outside world to my WAN interface from entering. At the same time, I want to have my private subnet pass through this router, with no restrictions, out to the internet (NATTED of course). I noticed that when I enable the restrictions on the inbound side of the WAN interface....my private subnet loses access to the outside (example:

http://www).

So when I set an inbound access list on the WAN interface of the router, what command(s) is needed to ensure I can still pass through from the inside?

Apparently, the NAT is not opening a return path for my private subnet's requests for some reason when my access list is enabled.

 

[CHM1]

For debugging, I suggest you add &quot;log&quot; on every item of your ACL and add, at the end 'deny ip any any log'.
Then you try to connect using your serial interface while using the console port of the router with a terminal to see the logged messages; then you can see what's happening better.

 

[ChrisAC]

Just because the router is NATing outbound traffic, it isn't stateful on a router and so every return packet will be blocked unless the ACL specifically lets it through.

With your ACL you may be finding that when a client makes a DNS request, the reply from the server to the client will be blocked. You may need to allow high UDP ports back in, ie. above 1024 to allow a server to client reply.

Check your logs.

Chris.


**********************
Chris Andrew, CCNA, CCSA
chris@iproute.co.uk
**********************

 

[garbo]

Hi,
I had the same problem, and solved it first by allowing all of the high port numbers greater than 1023. This will also let you ftp etc, as you will find that does not work either. This opens you up for a whole variety of attacks, but that is the limitation of ACL's.
The best way I found to deal with the &quot;established&quot; connections, and stop all of this ACL management, was to go in for a small PIX firewall. I have a few pix506's installed, and they are a very cost effective way of allowing this type of traffic, or &quot;established&quot; in the acl world. It actually marks outgoing traffic, and waits for the reply, using &quot;fixup protocols&quot;, all very neat, and it also has a nice gui too. The rest of the acl's can also be incorporated, and it also handles NAT well too.

 

[IllegalOperation]

Thanks for the info guys. Very helpful. I have yet another question.

I was told that if I have a Public IP address on my WAN interface, and is unprotected (no access list defined for it) - that is ok. I was told the only thing I need to worry about is telnet and finger, as long as I have NAT seperating that address with my inside network. Is that all true? I think that more security would be needed on top of NAT, especially if there is a public IP on my WAN interface that is out in the complete open.

 

[ChrisAC]

Rubbish! Get a firewall.

Chris.


**********************
Chris Andrew, CCNA, CCSA
chris@iproute.co.uk
**********************