Newbie trying to create ACLS on Cisco Router 1800s

Unanswered Question

We are setting up a connection between our primary site and a replication site. I have setup a router at each site and they connect via a T1. I now have connectivity between the two sites, but I want to implement security between the two sites to limit the traffic that can go through. Can someone help me with the commands? I have no real experience with ACLs, so I keep cutting myself off when I try to create them. Here is the situation:


Network 1: 192.168.1.x (255.255.255.0)

Network 2: 192.168.9.x (255.255.255.0)


Router 1: 192.168.12.10 (e0/0)

192.168.15.2 (Serial0/0)


Router 2: 192.168.9.10 (e0/0)

192.168.15.1 (Serial0/0)


Anyway, I would like to limit traffic between the two networks via the following:


Two hosts on the 192.168.1.x network should be able to use TCP ports 3218 and 3682 for replication to the 192.168.9.x hosts. (The same goes for the other direction).


I want to also allow telnet, ping, and smtp from the 192.168.1.x network (and the router itself in .12 network) to the other side so I can manage the router and send notifications.


Can someone tell me how to get started with the commands?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Pavel Bykov Wed, 08/22/2007 - 09:17
User Badges:
  • Silver, 250 points or more

Normally, the hardest part is defining the traffic flows.


I would recommend applying ACLs on the interface that routes Network 1 and Network 2.


Here is a command reference. It could be confusing, but scroll down to the example. Configuration is not going to be hard. Really.

http://www.cisco.com/en/US/customer/products/ps6350/products_command_reference_chapter09186a0080446247.html#wp1131458


Thanks for the advice. I have tried to start out by applying ACLs on Network 1 on the Serial Interface, which does the routing. Here are the statements I have tried:


access-list 102 permit tcp 192.168.1.0 0.0.0.255 192.168.9.0 0.0.0.255 eq 3218

access-list 102 permit tcp 192.168.1.0 0.0.0.255 192.168.9.0 0.0.0.255 eq 3682

access-list 102 permit tcp 192.168.1.0 0.0.0.255 192.168.9.0 0.0.0.255 eq telnet

access-list 103 permit tcp 192.168.9.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 3218

access-list 103 permit tcp 192.168.9.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 3682


interface Serial0/0/0

description T1 Interface to Sungard

ip address 192.168.15.2 255.255.255.252

ip access-group 103 in

ip access-group 102 out

encapsulation ppp


After doing so, for example, I can no longer telnet from my desktop on 192.168.1.x network to the remote router 192.168.15.1.


Am I on the right track? What have I missed? Do I need to later place ACLs on the other router also, or is it enough to place in and out ACLs on the one side?

jwdoherty Wed, 08/22/2007 - 11:16
User Badges:

You need to permit the return of your TELNET traffic. (Missing in access list 103.)


Normally you place ACLs to block/drop packets as early as possible. This avoids processing them or wasting bandwith. However, given the purpose of this link, having your ACLs where you do, shouldn't be an issue.

So are you sayng that I need to add something like:

access-list 103 permit tcp 192.168.15.0 0.0.0.255 192.168.1.0 0.0.0.255 eq telnet


I tried this, but still can't get a telnet connection.


Also, are you suggesting that it would be better for me to attach the ACLs to the FE0/0 instead of the Serial interface?

jwdoherty Wed, 08/22/2007 - 11:50
User Badges:

Off the top of my head, don't recall what ports TELNET uses for return packets. Something like


access-list 103 permit tcp 192.168.15.0 0.0.0.255 eq telnet 192.168.1.0 0.0.0.255


might do the trick.


Ideally, you would normally attach ACLs as inbound on both routers' LAN interfaces. However, don't forget the implicit deny all at the end of an ACL. To counter this, your 102 list, used LAN side's input, would need to append something like:


access-list 102 deny ip 192.168.1.0 0.0.0.255 192.168.9.0 0.0.0.255

access-list 102 permit ip any any


Oh, if you add an explicit deny any any at the end of the list, with a log keyword, you can see what's being rejected.


Jon Marshall Wed, 08/22/2007 - 23:04
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Hi


Just to clarify. Your access-list 102 says


access-list 102 permit tcp 192.168.1.0 0.0.0.255 192.168.9.0 0.0.0.255 eq telnet.


Yet you are trying to telnet to a 192.168.15.x address and not a 192.168.9.x address so the access-list will drop this traffic on the way out.


Either 192.168.15.1 is a typo or you need


access-list 102 permit tcp 192.168.1.0 0.0.0.255 192.168.15.0 0.0.0.255 eq telnet


And you would also have to add a line into access-list 103 to allow the traffic back in ie.


access-list 103 permit tcp 192.168.15.0 0.0.0.255 eq telnet 192.168.1.0 0.0.0.255


HTH


Jon



jwdoherty Thu, 08/23/2007 - 07:14
User Badges:

Jon makes an excellent catch!


You wrote "After doing so, for example, I can no longer telnet from my desktop on 192.168.1.x network to the remote router 192.168.15.1."


As Jon notes, the 15 subnet is not in your ACLs so Telnet access is blocked to the routers' WAN IPs (although not to the far side LAN outbound, but was inbound).


You did propose the correct ACL "access-list 103 permit tcp 192.168.15.0 0.0.0.255 192.168.1.0 0.0.0.255 eq telnet" but as Jon notes, it should be within the 102 access list. And you still needed "access-list 103 permit tcp 192.168.15.0 0.0.0.255 eq telnet 192.168.1.0 0.0.0.255", as both Jon and I supplied for the return traffic.


Do note that if you Telnet from your local router to the far side router, the above would still fail because the router normally sources from it closest interface. Then you would also need ACLs to permit traffic to/from you need local router. Such as:


access-list 102 permit tcp 192.168.15.0 0.0.0.255 192.168.15.0 0.0.0.255 eq telnet

access-list 103 permit tcp 192.168.15.0 0.0.0.255 eq telnet 192.168.15.0 0.0.0.255


If you want to reduce the number of ACLs for Telnet, you can:


not worry about the subnets


access-list 102 permit tcp any any eq telnet

access-list 103 permit tcp any eq telnet any


or lump them together


access-list 102 permit tcp 192.168.0.0 0.0.15.255 192.168.0.0 0.0.15.255 eq telnet

access-list 103 permit tcp 192.168.0.0 0.0.15.255 eq telnet 192.168.0.0 0.0.15.255

Yes, that was just a cut from the wrong place.


It is:

access-list 102 permit tcp 192.168.1.0 0.0.0.255 192.168.15.0 0.0.0.255 eq telnet

access-list 103 permit tcp 192.168.15.0 0.0.0.255 192.168.1.0 0.0.0.255 eq telnet


I see that in one you have the eq telnet on the end and on the other before the destination? I assume that makes no difference though?


The problem is that I don't get to the telnet prompt. I just get a blinking cursor, but not a denied either.


Anything else I might be missing?

jwdoherty Thu, 08/23/2007 - 07:37
User Badges:

Placement of the "eq telnet" does matter. Whether you want to match against the destination port or source port.


Try

access-list 103 permit tcp 192.168.15.0 0.0.0.255 eq telnet 192.168.1.0 0.0.0.255


I suspect you didn't catch my prior post. If the above corrects the problem, you might also try the Telnet ACL variants I provided in my prior post.

jwdoherty Wed, 08/22/2007 - 09:26
User Badges:

Something that catches beginners is ACLs have an implicit deny everything at the end of the list. So if you don't explicitly permit the traffic you desire, once you define the ACL, it will be blocked.

Thanks for the help. OK. Telnet is working properly right now, although I must say I'm not confident that I can pull off the rest of the ACLS to restrict it the way I want. I'm not sure if I need to put the ACLs on both routers, or just one and what direction they should go. I want to allow ports 3218, 3682, and ping both ways.

Joseph W. Doherty Thu, 08/23/2007 - 11:58
User Badges:
  • Super Bronze, 10000 points or more

Congratulations!


Well you often learn best by doing.


If you have any excess equipment, making a small lab will allow you to try such changes without breaking production. Or, if you don't have the equipment, there are some Cisco simulator products on the market you might investigate.


Lastly, don't forget the ACL logging or debug may provide insight why your traffic isn't flowing through the ACL as expected.

Actions

This Discussion