1. Home
  2. Cisco Systems
  3. Access lists

Access lists

Hello there,

I have a question about access lists. We have a simple network topology with 2 x 2811 routers interconnected by their eth0/0 interfaces. We have a development network hanging off the eth0/1 interface of router A and a production network hanging off the eth0/1 interface of router B.

We require hosts on the production network to be able to ssh and http to the development environment. However, we do not want the development machines to initiate connections to the production environment. I have applied an outbound access list on the eth0/0 interface of router B allowing traffic to the development environment. I have also applied an inbound access list on the same interface denying the development vlans any traffic. This seems to be blocking the reply traffic for the connections initiated from teh production environmet - is this expected? How can I allow connections from clients on the production network through to the dev environment but block connections being initiated from the dev environment?

Thanks, Nick

Reply to
njwhitworth
Loading thread data ...

Very simply, you need to poke holes in the inbound ACL for telnet/ ssh. The ACLs are black/white mechanisms, and will deny or allow whatever you set, and have no understanding of sessions like NAT/PAT. That being said, I would consider using a single access-list on the inbound of E0/0 on Router A allowing telnet/ssh and nothing else. Even if the dev servers initiated a connection outbound, it would not be allowed back in, and this would work smoothly. The only risk of course is someone running a service on port 22 in your production farm and connecting to it from dev, but even your solution would allow this to happen. Just my 2 cents.

Reply to
Trendkill

Hi Nick,

We have a very similar setup and use a router with ACL to manage access. Our LAB uses 192.168.*.* addressing and has NAT to allow access to/from the "production" environment. This means all inwards access has to be planned access to "map" the desired inward path to the appropriate place. In addition, we also use an ACL on the LAB side that - Allows all ESTABLISHED sessions to exit the LAB. This means we only need to consider who wants to get in and all matching OUTWARD access is automatically allowed. Allows some specified sessions to be initiated from within the LAB. All other traffic is blocked. ALL entries in the ACL include the LOG option, so we know what is and is not being PERMITTED.

This allows "external" users to enter the lab and perform planned work, but prevents all other forms of work not explicitly allowed. No outward initiated sessions are allowed UNLESS they have been explicitly allowed.

I hope this helps..................pk.

Reply to
Peter

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.