ACL on 2600 series router

[william.glover]

Hello, I have a 2600 and a problem. I need to host an ftp server using port forwarding. My problem is that on my incoming ACL, i have an established command at the the bottom.

Permit tcp host *.*.*.* eq 21 host *.*.*.* eq 21 ....

permit tcp any any established

I have the nat translation mapped correctly, as i can connect from the outside as long as the established command is not in my ACL.

I've even moved to reflexive acls with the same problem. This is a healthcare place, and i know nat is doing a good job, but i want to be as invisible as humanly possible.

Is there any way that i can tell this router to disregard the established command? Any help or idea or opinions are greatly appreciated. Thanks for your time.

[william.glover]

Forgot to add. if i leave the established part in there and tell the acl to forward ftp traffic to the entire subnet then the client tries to connect to the server but fails. That could maybe have a workaround, but the catch is that im running a seperate ftp server for internal network scanning. and this carries some confidential information.

[Richard Burts]

I have read your message several times and am confused about what your problem is. You seem to be saying that if you remove the established statement then ftp works and if you include established it does not. However I do not know of any way that adding permit tcp any any established could break the functionality. There must be something else that is changing.

Also I not in your post this line:

Permit tcp host *.*.*.* eq 21 host *.*.*.* eq 21 ...

But it is not true that 21 is both the source port and the destination port. 21 will be the source or the destination depending on whether it is going to the server or coming from the server and depending on whether the access list is to be applied inbound or outbound. (if you are using the established concept the access list should be an inbound list since there is no concept of established on an outbound list)

Can you clarify the situation and the problem?

HTH

Rick

[william.glover]

passive ftp. forced to port 21.

and yep the acl is inbound. looks like this at the moment,

deny ...

deny...

evaluate tcp-tempflex

evaluate udp-tempflex

permit tcp any any established log

permit udp any any log

outgoing is like this

deny...

permit tcp host x.x.x.x eq 21 host x.x.x.x eq 21 reflect tcp-tempflex...

(have a couple of others in here too, one is a voip server on udp. same server and it works 100% of the time.)

permit tcp any any

permit udp any any

and yep with the stablished command it does not work.

without it it works just fine.

the established command is at the bottom. the allow 21 is at the top.

or it was rather until i tried fiddling with the reflexives. now the allow ftp is stuck in there. either way its the same scenario. with estab=no connect without=connect

I suppose what im asking. Is there a way to make packets that match an argument in the acl not process the rest of the acl?

ive been fighting, and fingering, and cussing, and tweaking this problem for a good 2 months.

I know im doing it backwards by putting in denies instead of allowing certain ports and letting the implicit deny catch everything else.

on the plus side i will never have to look up the password to that router again.

[Richard Burts]

William

I have a couple of comments but not any solutions at this point.

As for your comment about a way to make packets that match an argument in the acl not process the rest of the acl. If I understand what you are saying, this is in fact the behavior of the IOS. If a packet matches an entry in the access list, the IOS takes whichever action was specified (permit or deny) and does not evaluate any other statements in the acl.

It makes me wonder if we are saying the same thing: when you say matches a parameter and I say matches an entry in the acl. Parameters in the acl statement would be source address, destination address, perhaps source port and/or destination port. A packet must match every parameter in the entry for the acl to take action on the packet.

I am extremely puzzled about the situation you are describing. If you have an access list that is allowing certain traffic (such as ftp) and you add another line that says permit tcp established you have not added anything that says deny and it is extremely odd that the acl should start denying if the only thing that you added was a permit established. Perhaps you could post the results of the command show access-list before and after adding the established entry. If for some reason you are reluctant to post that on the forum you might email the results to me.

HTH

Rick

[william.glover]

I'm puzzled about it myself. I was always taught that once it matches it discards the rest of the acl. i will do some data gathering and post it on here. Be back soon.

[william.glover]

Just as a test, i rewrote two very simple acls. looking at them i think im doing something unrelated thats causing my problem but im not sure what it is. at any rate here they are.

permit tcp host (outside ip) eq ftp host 192.168.1.29 eq ftp log

permit tcp any any established log (6811 matches)

permit udp any any log (211 matches)

that does not connect

permit tcp host (outside ip) eq ftp host 192.168.1.29 eq ftp log

permit tcp any any log (1123 matches)

permit udp any any log (118 matches)

that one does connect.

and heres the translation that pops up when there is a connection.

tcp (outside local ip):21 192.168.1.29:21 (outside client ip):1073 (outside client ip):107

both of the above acls have one other statement that allows a voip server on the same box that is hosting the ftp. no problems with that since it is udp.

either ive completely screwed up the acls and the permit any is letting it through. or its not logging the hits to the list. i did try it backwards with the client and outside ip's reversed and the client couldnt connect at all.

[erickflamenco]

Hello,

Please take a look to this link

http://www.cisco.com/en/US/about/ac123/ac147/ac174/ac199/about_cisco_ipj_archive_article09186a00800c85a7.html

And then change the source port to 20.

Erick

[erickflamenco]

Please, forget it about port 20, just don't tight source port.

access-list x permit tcp host ip.address host ftp.srv.ip.add eq ftp

Erick

[william.glover]

alright gave that a shot heres the acl

permit tcp host (outside ip) host 192.168.1.29 eq ftp log

permit tcp any any established log (7028 matches)

permit udp any any (177 matches)

nada.

permit tcp host (outside ip) host 192.168.1.29 eq ftp log

permit tcp any any log (141 matches)

permit udp any any log (8 matches)

connected right up.

Mind blowingly aggravating isnt it? luckily this is a mental health place.

[Richard Burts]

William

If I understand your post correctly it looks like you are building the access with the address that the client will be translated to going outside. Try building the access list with the client inside address instead.

If that does not do it, can you be a little more specific about the topology and the addressing used (client, server, and how translation is being done).

HTH

Rick

[william.glover]

Erm, do you mean build it up as permit tcp (inside server) ... (outside ip)....

As to topology..... central router is a 2600 with 3 ports. 2 fa and one serial t1. fa0/1 is linked to a cable modem with a static public ip. fa0/0 is internal on a 192.168.1.0 going to 3 catalyst switches. the serial link is on the .2.0 sub which feeds the .3.0 sub thorough another 2600.

client.... the client connecting is using leapftp at the moment, have tried others such as ws-ftp the windows ftp client etc.

server. bulletproof ftp server on a dell poweredge.

I am getting either over my head or confused. im fairly sure im answering questions you didnt ask now.

but the translation i did on the router. ip nat inside source static 192.168.1.29 21 (outside ip) 21 extendable.

Sorry for the long reply time. My boss decided things needed picked up and carried from one place to the other. /shrug.

[Richard Burts]

William

Yes you did answer some questions that I did not ask. But that is ok. (It is more of a problem to have too little information than to have too much.)

I am not clear whether you are saying this is an ongoing active issue or not. If this is still an active issue then I would like you to supply a simple explanation of the situation: address of the client, which interface the client connects to, how NAT is specified for the client, which interface the server connects to, address of the server, what is the access list content, and what are the results.

HTH

Rick

[steve.busby]

William--If this is still a non-working issue, can you provide the current applicable parts of your configuration? I'm thinking what Rick (and others who read this) need are not only what you want to do, but how exactly you're configuring your router. I would like to see each interface configuration, ALL of the NAT configuration, and finally your ACL(s).