Large ACLs breaking production router

[GeneralDzur]

I could really use you guys' help...

We've been trying to get a static mapping (Port Forwarding) to allow requests hitting our Router's Public IP (xx.xx.197.134) on five certain ports to be forwarded to an internal server 192.168.25.6.

For some reason, the router does NAT fine, but when these ACL's are applied (below), it breaks the traffic. I'm at my wits end...I've been poring over these for 5 days. If anyone see's a flaw in these lists, please tell me.

\\\\\\\\\\\\\\\BEGIN////////////////

service timestamps debug uptime
service timestamps log uptime
service password-encryption
no service udp-small-servers
no service tcp-small-servers
!
hostname 818NAT
!
logging buffered
no logging console

enable secret XXXXX
!
!
!
!
ip subnet-zero
ip source-route
ip flow-cache entries 4029
ip flow-cache timeout active 5
ip cef
no ip domain-lookup
!
!
!
!
!
!
interface Ethernet0/0
description INTERNET
ip address xx.xx.197.134 255.255.255.252
ip access-group Web-FTP-in in
no ip unreachables
no ip accounting access-violations
ip nat outside
no ip route-cache flow
no ip mroute-cache
no cdp enable
!
interface Ethernet0/1
description Internal LAN
ip address 192.168.25.1 255.255.255.0
ip access-group Web-FTP-out in
ip nat inside
no ip route-cache flow
no ip mroute-cache
speed 100
full-duplex
!
ip nat inside source list 1 interface Ethernet0/0 overload
ip nat outside source static xx.xx.197.134 192.168.25.6
ip classless
ip route 0.0.0.0 0.0.0.0 xx.xx.197.133
no ip http server
!
ip access-list extended Web-FTP-in
remark ### COUNTRY BLOCKS ###
remark - Korea Networks TLH 3 Dec 01
deny ip 128.134.0.0 0.0.255.255 any log
deny ip 147.46.0.0 0.0.255.255 any log
deny ip 134.75.0.0 0.0.255.255 any log

! -- CONTENT REMOVED FOR BREVITY
! -- NOT ESSENTIAL TO CONFIG
! -- JUST AN IP BLOCK-LIST

deny ip host 206.67.134.135 any log
deny ip host 65.54.252.230 any log
deny ip host 160.130.13.106 any log
deny ip host 128.190.218.198 any log
deny ip 10.0.0.0 0.255.255.255 any
deny ip 127.0.0.0 0.255.255.255 any
deny ip 172.0.0.0 0.240.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
permit icmp any any echo-reply
permit icmp any any time-exceeded
permit icmp any any unreachable
! -- ***This is the attempted NAT port forward***
! --
permit tcp 140.175.248.0 0.0.0.255 gt 1023 host xx.xx.197.134 range 4350 4351
permit tcp 140.175.248.0 0.0.0.255 gt 1023 host xx.xx.197.134 eq 5052
permit tcp 140.175.248.0 0.0.0.255 gt 1023 host xx.xx.197.134 eq 5601
permit tcp 140.175.248.0 0.0.0.255 gt 1023 host xx.xx.197.134 eq 9998
permit tcp 134.135.1.128 0.0.0.127 gt 1023 host xx.xx.197.134 range 4350 4351
permit tcp 134.135.1.128 0.0.0.127 gt 1023 host xx.xx.197.134 eq 5052
permit tcp 134.135.1.128 0.0.0.127 gt 1023 host xx.xx.197.134 eq 5601
permit tcp 134.135.1.128 0.0.0.127 gt 1023 host xx.xx.197.134 eq 9998
permit tcp any gt 1023 host xx.xx.197.134 eq 443
permit tcp any gt 1023 host xx.xx.197.134 eq 80
permit tcp any gt 1023 host xx.xx.197.134 eq 110
permit tcp any gt 1023 host xx.xx.197.134 eq 995
permit tcp any gt 1023 host xx.xx.197.134 eq 25
permit tcp any gt 20 host xx.xx.197.134 eq 21
permit tcp xx.xx.150.100 host xx.xx.197.134 eq 23
permit tcp xx.xx.197.162 host xx.xx.197.134 eq 23
deny ip any any log
!
ip access-list extended Web-FTP-out
permit icmp host 192.168.25.6 140.175.248.0 0.0.0.255 echo-reply
permit icmp host 192.168.25.6 140.175.248.0 0.0.0.255 time-exceeded
permit icmp host 192.168.25.6 140.175.248.0 0.0.0.255 unreachable
permit icmp host 192.168.25.6 134.135.1.128 0.0.0.127 echo-reply
permit icmp host 192.168.25.6 134.135.1.128 0.0.0.127 time-exceeded
permit icmp host 192.168.25.6 134.135.1.128 0.0.0.127 unreachable
permit icmp host 192.168.25.6 host xx.xx.197.133 echo-reply
permit icmp host 192.168.25.6 host xx.xx.197.133 time-exceeded
permit icmp host 192.168.25.6 host xx.xx.197.133 unreachable
deny icmp 192.168.25.6 any log
permit icmp any any echo-reply
permit icmp any any time-exceeded
permit icmp any any unreachable
permit tcp host 192.168.25.6 140.175.248.0 0.0.0.255 eq 4100
permit tcp host 192.168.25.6 140.175.248.0 0.0.0.255 eq 4300
permit tcp host 192.168.25.6 140.175.248.0 0.0.0.255 eq 4351
permit tcp host 192.168.25.6 140.175.248.0 0.0.0.255 eq 5051
permit tcp host 192.168.25.6 140.175.248.0 0.0.0.255 eq 5600
permit tcp host 192.168.25.6 140.175.248.0 0.0.0.255 eq 9999
permit tcp host 192.168.25.6 134.135.1.128 0.0.0.127 eq 4100
permit tcp host 192.168.25.6 134.135.1.128 0.0.0.127 eq 4300
permit tcp host 192.168.25.6 134.135.1.128 0.0.0.127 eq 4351
permit tcp host 192.168.25.6 134.135.1.128 0.0.0.127 eq 5051
permit tcp host 192.168.25.6 134.135.1.128 0.0.0.127 eq 5600
permit tcp host 192.168.25.6 134.135.1.128 0.0.0.127 eq 9999
permit tcp 192.168.25.0 0.0.0.255 any eq 80
permit tcp 192.168.25.0 0.0.0.255 any eq 25
permit tcp 192.168.25.0 0.0.0.255 any eq 110
permit tcp 192.168.25.0 0.0.0.255 any eq 995
permit tcp 192.168.25.0 0.0.0.255 any eq 443
permit tcp host 192.168.25.2 any eq 21

deny ip any any log
!
access-list 1 remark ***Internal NAT pool***
access-list 1 permit 192.168.25.0 0.0.0.255
access-list 10 remark ***Allowed Telnet Hosts***
access-list 10 permit xx.xx.150.100
access-list 10 permit xx.xx.197.162
!

line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
access-class 10 in
password XXXXXXX
login
!
no scheduler allocate
end

 

[ChrisAC]

So what breaks? All other traffic not related to the port forwarding?

'sh access-lists' will show the hits against the acl's and I'm betting that you are getting a lot of hits against the last rule, deny ip any any log.

Your outside access list deals only with traffic to your internal server that you are port forwarding to. At the end of that you have a 'deny ip any any'.

On your inside acl you have this to allow the rest of the network outbound traffic on these ports ..

A

permit tcp 192.168.25.0 0.0.0.255 any eq 80
permit tcp 192.168.25.0 0.0.0.255 any eq 25
permit tcp 192.168.25.0 0.0.0.255 any eq 110
permit tcp 192.168.25.0 0.0.0.255 any eq 995
permit tcp 192.168.25.0 0.0.0.255 any eq 443
permit tcp host 192.168.25.2 any eq 21

Presuming that this is for normal internet traffic (web browsing, email ftp etc..), firstly you haven't allowed outbound DNS so how does anyone on the LAN resolve internet domain names and secondly all the reply traffic to this outbound traffic will be dropped by the last line of the outside acl (deny ip any any).

Routers are not stateful like firewalls and so they won't automatically allow reply traffic back into the network. The best practice with router acl's is to block all unwanted traffic and then have a 'permit ip any any' at the bottom to ensure that everything else works okay, otherwise everything not specifically permitted in the rules will be dropped.

Chris.




**********************
Chris A.C, CCNA, CCSA
**********************

 

[GeneralDzur]

Chris,

The final entry (deny ip any any) is showing a lot of hits, but I'm not sure why. I've added the following lines to each ACL, but I can't test them until tonight (Morning, for Stateside. I'm 10 hours ahead).

1) Yes, the other "permit" rules for specific ports are for regular LAN users to browse the internet.

~ADDED~

to Outbound ACL:
permit udp 192.168.25.0 0.0.0.255 any eq 53


to Inbound ACL:
permit udp any host 81.31.197.134 eq 53


2) Wouldn't these entries permit returning traffic to enter the LAN? Unless I'm mistaken, returning traffic uses a random port # higher than 1023.

permit tcp any gt 1023 host 81.31.197.134 eq 443
permit tcp any gt 1023 host 81.31.197.134 eq 80
permit tcp any gt 1023 host 81.31.197.134 eq 110
permit tcp any gt 1023 host 81.31.197.134 eq 995
permit tcp any gt 1023 host 81.31.197.134 eq 25

- stephan

 

[ChrisAC]

No, you are allowing connections from anywhere on the internet with a high port number to connect to your site on those ports (444, 80, 110 etc.) Of course, your side of the connection will be on the high port number, NOT the server side. The destination ports for the connections coming back in will be on high port numbers, not the port that the service is running on. The SOURCE ports will be 443, 80, 110 etc.. but you have allowed connections to those destination ports.

eg.

For a port 80 connection ..

client (high port) >>>>> web server (port 80)

web server (port 80) >>>>> client (high port)

So the DESTINATION port will be above 1023, not port 80 but your acl only allows the destination port to be that of the service that the outbound connection was made to.

So for example this line;

permit tcp any gt 1023 host 81.31.197.134 eq 80

.. says allow any host with a high source port to connect to my IP address on port 80. The ports will actually be the other way around. The inbound connections will not be to port 80 because the outbound connection did not have a source of port 80, it had a destination of port 80.

Chris.



**********************
Chris A.C, CCNA, CCSA
**********************

 

[GeneralDzur]

In that case, my statements would need to read

permit tcp any eq 80 host 81.31.197.134 gt 1023

Is that right?

- stephan

 

[ChrisAC]

Well, yeah that should work but would just take the opposite approach of blocking all unwanted traffic/ports and then just allowing everything else with a 'permit ip any any rule'.

access-list 123 deny tcp any host 81.31.197.134 <some port>
access-list 123 deny tcp any host 81.31.197.134 <some other port>
acess-list 123 <other stuff that you want to block>
access-list 123 permit ip any any

If you want to do it the other way just use something like;

access-list <snip .. all the stuff that you want to block>
access-list 123 permit tcp any host 81.31.197.134 gt 1023
access-list 123 permit udp any host 81.31.197.134 gt 1023

I wouldn't bother specifying every source port.

Chris.


**********************
Chris A.C, CCNA, CCSA
**********************

 

[GeneralDzur]

I don't really want to lock down each port, but this is a DoD network, and the Powers that Be want it really locked down.

So to summarize, I need to set it up like this?

permit tcp any host xx.xx.197.134 gt 1023

?

- stephan the confused

 

[BuckWeet]

Run IOS FW so you can run ip inspection, it will make ACLs much easier to work with.. The router will track the TCP session...

 

[GeneralDzur]

Basically I'm stuck with the IOS that I have. Uncle Sam doesn't want to dish out the cash for a new one, and we can't seem to find our contract.

So was that line (permit tcp any host xx.xx.197.134 gt 1023) inbound correct? Is that the correct way to allow returning connections to my NAT'd computers inside?

- Stephan

 

[ChrisAC]

So was that line (permit tcp any host xx.xx.197.134 gt 1023) inbound correct?

Basically, yes! It will allow inbound connections from servers back in as long as the original outbound connection was made with a source port of greater than 1023 (which they always are for the most part). You should put a line in for udp as well.

I have to say that I'm amazed that the DoD won't pay for a proper firewall. A Pix 506E would give you 'real' security with stateful rules and a default drop for anything not permitted in the rulebase.

Keep putting the pressure on.

Chris.

**********************
Chris A.C, CCNA, CCSA
**********************

 

[GeneralDzur]

You're right Chris, a Pix would be nice. I'm still pushing to get one.

Thanks for your help here. I have one more question, about my NAT statement.

Is this (below) correct for NAT'ing all public connections (forwarding) to the internal server, on the 5 ports?

ip nat inside source static tcp 192.168.25.6 4350 interface e0/0 4350 extendable
ip nat inside source static tcp 192.168.25.6 4350 interface e0/0 4351 extendable
ip nat inside source static tcp 192.168.25.6 5052 interface e0/0 5052 extendable
ip nat inside source static tcp 192.168.25.6 5601 interface e0/0 5601 extendable
ip nat inside source static tcp 192.168.25.6 9998 interface e0/0 9998 extendable



- stephan

 

[ChrisAC]

Basically, yes although you shouldn't need 'extendable' on the end.

Chris.

**********************
Chris A.C, CCNA, CCSA
**********************

 

[GeneralDzur]

Thanks for all your help, Chris.

Still working on a Pix...but I'm not sure if it's going to happen, so I'm stuck with using a router for our firewall.

- stephan