locking down inside interface on router

[mmrozek]

i have a cisco 1720 at home that is sitting behind a dsl connection. my objective is learn as much as possible about the traffic that goes through it and how to control it with access-lists.

the reason i'm posting this conversation is because i go to apply an access-list like this:

ip access-list extended f0-in-2

permit tcp any any eq telnet

permit tcp any any eq www

permit udp any any eq domain

permit udp any any eq isakmp

permit tcp any any eq smtp

permit tcp any any eq pop3

permit udp any any eq netbios-ns

permit tcp any any eq 1206

permit udp any any eq 62515

permit udp any any eq 1900

permit udp any any eq 10000

permit tcp any any eq 3389

permit icmp any any

permit esp any any

permit udp any any eq tftp

deny ip any any

...to the incoming traffic on my inside interface and it stops my nat config from working (below).

ip nat inside source static tcp 10.10.10.11 3389 interface Ethernet0 3389

ip nat inside source static tcp 10.10.10.11 80 interface Ethernet0 80

ip nat inside source static tcp 10.10.10.11 21 interface Ethernet0 21

I wouldn't think these two things would conflict but do they? Once I apply the access-list to the interface, I am not able to connect to the computer through those (3) ports. Any ideas?

[Richard Burts]

Michael

Here are a couple of points that may shed some light on your issue.

- the access list ends with deny ip any any so anything that is not specifically permitted will be denied. (I think it sometimes is helpful to explicitly code the deny any any as you have done since it may give some visibility about how much traffic is falling through and being denied.)

- one of your static translations is for tcp 21 which is the FTP control port. There is no permit in the access list for tcp 21. So it is fairly easy to see why this translation would not work since the access list will deny the traffic.

- it is a bit more subtle to see why the other two translations do not work since the access list does have permits for tcp 3389 and for tcp 80 (www). And this may be the most significant part of the discussion: the static translations are translating source ports. But the access list has permits for the destination ports. You may need to revise the access list and include some permits for traffic specifying source ports in addition to specifying destination ports.

HTH

Rick

[mmrozek]

so here is what i'm thinking:

i don't have the IOS feature set to allow for CBAC so i'm going to go about this differently (assuming that would be one way of doing this). i have two computers which i want to have locked down as much as possible (for learning purposes). i'm going to place both of them in different subnets. the server computer (10.10.10.11), will have an access-list that allows all traffic to go through the inbound direction of the inside interface. i will create another subnet for the other computer (10.10.11.11) and control it's traffic a lot more with a more restrictive access-list for 10.10.11.0 traffic.

does that sound like a good idea?

[Richard Burts]

Michael

As a learning exercise it sounds ok. Are you thinking of the access list to control interaction between the server and the other computer or are you thinking of controlling interaction between both of these and the outside world? Bear in mind that with both machines connected behind the inside interface of the router that the router interface can have only one access list inbound and one access list outbound.

HTH

Rick

[mmrozek]

Rick,

Do you recommend a different path for this situation? Those were the best ideas I could come up with what I currently know. I understand that a www request will come in on port 80 and leave on a different port so I couldn't think of a way to let that packet out without opening almost everything for the server.

When I was thinking about using the differnet subnets, I was thinking about both ideas (controlling interacation to the Internet and between computers). However, I'd probably need another router to do that, wouldn't I? Or maybe I could with the correct access-list and subnetting?

I guess what I'm looking for is the general direction I should take to pursue locking this down. When you say the idea is "ok", do you mean that there are much better ideas? Thanks Rick.