NAT issue

[albertobrivio]

Dear All,

I have a simple configuration, a DSL, some users browsing internet, sending/receiving e-mails, and so on,

and ther's a public web server.

It seems to be all up and running, but in order to publish web server I have to open a lot of tcp ports

other than 80, because web server seems to answer through the port owned by client starting request.

This is the configuration:

webserver 192.168.100.253 , public 212.110.x.y, it's the LAN's proxy server

****************************************

version 12.3

no service pad

service timestamps debug uptime

service timestamps log uptime

service password-encryption

!

no aaa new-model

ip subnet-zero

no ip source-route

!

!ip audit notify log

ip audit po max-events 100

no ftp-server write-enable

!

!

interface Ethernet0

ip address 192.168.101.254 255.255.255.0 secondary

ip address 192.168.100.254 255.255.255.0

ip access-group 101 in

ip nat inside

hold-queue 100 out

!

interface ATM0

no ip address

no atm ilmi-keepalive

pvc 8/35

encapsulation aal5mux ppp dialer

dialer pool-member 1

!

dsl operating-mode auto

!

!

interface Dialer0

ip address negotiated

ip nat outside

encapsulation ppp

dialer pool 1

dialer-group 1

ppp authentication chap pap callin

ppp chap hostname xxxxxxxxxxxxxxxxxxxx

ppp chap password yyyyyyyyyyyyyyyyyyyy

!

ip nat inside source list 10 interface Dialer0 overload

ip nat inside source static tcp 192.168.100.253 22 212.110.x.y 22 extendable no-alias

ip nat inside source static tcp 192.168.100.253 80 212.110.x.y 80 extendable no-alias

ip classless

ip route 0.0.0.0 0.0.0.0 Dialer0

no ip http server

no ip http secure-server

!

access-list 10 permit 192.168.100.0 0.0.0.255

!

dialer-list 1 protocol ip permit

!

access-list 101 permit icmp any any

access-list 101 permit tcp host 192.168.100.253 any eq domain

access-list 101 permit udp host 192.168.100.253 any eq domain

access-list 101 permit tcp host 192.168.100.253 any eq www

access-list 101 permit tcp host 192.168.100.253 any eq smtp

access-list 101 permit tcp host 192.168.100.253 any eq ftp

access-list 101 permit tcp host 192.168.100.253 any eq pop3

access-list 101 permit tcp host 192.168.100.253 any eq 1433

access-list 101 permit tcp 192.168.100.0 0.0.0.255 any eq pop3

access-list 101 permit tcp 192.168.100.0 0.0.0.255 any eq 1433

access-list 101 permit tcp 192.168.100.0 0.0.0.255 any eq ftp

access-list 101 permit tcp host 192.168.100.253 any range 0 10000 (without this line web is not published)

access-list 101 deny ip any any

!

line con 0

exec-timeout 120 0

login local

no modem enable

stopbits 1

line aux 0

line vty 0 4

access-class 30 in

exec-timeout 120 0

login local

!

scheduler max-task-time 5000

!

end

Regards

Alberto Brivio

[globalnettech]

Hello Alberto,

which web publishing software/application are you using ? Your problem sounds like it could be related to your web publishing software, rather than the router...

Regards,

GNT

[albertobrivio]

Hi,

that environment is managed by a customer of mine, but I know paltform is:

APACHE 2.0.52 DEBIAN GNU/Linux

If I enable log to ACL's line I have to write, you can see output here:

9w5d: %SEC-6-IPACCESSLOGP: list 101 permitted tcp 192.168.100.253(80) -> remote client address(3269), 1 packet

9w5d: %SEC-6-IPACCESSLOGP: list 101 permitted tcp 192.168.100.253(80) -> remote client address(3273), 1 packet

Regards

Alberto

[atif.awan]

The problem is not with the webserver. The webserver is responding just the way it should; using tcp 80 as the source port and the client's port as the destination port. The problem is with the way you have configured and applied the access-list. Usually in order to protect your internal LAN you apply a restrictive access-list on the outside interface in inbound direction. That way you can allow access to port 80 for your webserver but deny access to all other internal hosts.

My recommendation is to only have a non-spoofing access-list on your inside interface and have a more restrictive access-list on the outside interface. An example is:

ip access-list extended inside

permit ip 192.168.100.0 0.0.0.255 any

permit ip 192.168.101.0 0.0.0.255 any

deny ip any any log

ip access-list extended outside

permit tcp any 192.168.100.0 0.0.0.255 established

permit tcp any 192.168.101.0 0.0.0.255 established

permit udp any eq dns 192.168.100.0 0.0.0.255

permit udp any eq dns 192.168.101.0 0.0.0.255

permit tcp any host 212.110.x.y eq www

permit tcp any host 212.110.x.y eq ssh

This ACL might break some applications so you have to do some fine tuning after applying it inbound on Dialer0. You can put a deny ip any any log statement at the end of the outside ACL to see if legitimate traffic is being denied and if it is then add the respective entry in the ACL.

If you want to stick with your ACL then you do not have much choice but to add a statement of this sort:

access-list 101 permit tcp host 192.168.100.253 eq www any

[albertobrivio]

Hi,

thanks for your reply.

I'm going to try your tips.

Normally I manage Pix IOS,so in router environment I don't have much familiarity, but opening all outbound connections on eth0 and permit tcp established incoming on dialer 0..couldn't it be dangerous?

I agree about my much restrictive ACL , and as you can see, port 80 is free to run,but it seems to need other ports in order to answer client's request.

Regards

Alberto Brivio

[atif.awan]

Well you can make your inside ACL restrictive by letting your inside users access only services they are supposed to access; I am not against doing that as long as you have a policy stating what is and what is not allowed.

For the outside ACL there is not much you can do other than permitting all access to port 80 of your webserver. The normal security practice is to put such machines in a DMZ in order to limit the impact of a security incident. If you have the option of enabling IOS FW service on your router I will recommend that as it will ease up a lot of things.