NAT Problems Cisco 501 firewall

I have been working on this for days without success. All I am trying to do is forward a public IP address to a private IP address. Here's what I've got. It has to be something easy. I really only want to host a webserver. I can't even ping the public IP address. Any help would be much appreciated. Thanks. BTW, I am able to browse the web with the webserver.

public IP: 60.33.23.132 static IP: 192.168.1.17

Result of firewall command: "write terminal"

Building configuration... : Saved : PIX Version 6.3(3) interface ethernet0 auto interface ethernet1 auto nameif ethernet0 outside security0 nameif ethernet1 inside security100 enable password WnWty2YPL4jeoz0e encrypted passwd WnWty2YPL4jeoz0e encrypted hostname pixfirewall domain-name ciscopix.com fixup protocol dns maximum-length 512 fixup protocol ftp 21 fixup protocol h323 h225 1720 fixup protocol h323 ras 1718-1719 fixup protocol http 80 fixup protocol rsh 514 fixup protocol rtsp 554 fixup protocol sip 5060 fixup protocol sip udp 5060 fixup protocol skinny 2000 fixup protocol smtp 25 fixup protocol sqlnet 1521 fixup protocol tftp 69 names access-list 100 permit icmp any any echo-reply access-list 100 permit icmp any any time-exceeded access-list 100 permit icmp any any unreachable access-list 100 permit tcp any host 60.33.23.132 eq www access-list inside_access_in permit ip any any access-list inbound permit icmp any any access-list inbound permit tcp any host 60.33.23.132 eq www access-list inbound permit tcp any host 60.33.23.132 eq domain access-list inbound permit udp any host 60.33.23.132 eq domain pager lines 24 logging on mtu outside 1500 mtu inside 1500 ip address outside 60.33.23.50 255.255.255.248 ip address inside 192.168.1.1 255.255.255.0 ip audit info action alarm ip audit attack action alarm pdm location 192.168.1.20 255.255.255.255 inside pdm location 60.33.23.132 255.255.255.255 outside pdm logging informational 100 pdm history enable arp timeout 14400 global (outside) 1 interface nat (inside) 1 0.0.0.0 0.0.0.0 0 0 static (inside,outside) 60.33.23.132 192.168.1.17 netmask

In article , wrote: :I have been working on this for days without success. All I am trying :to do is forward a public IP address to a private IP address. Here's :what I've got. It has to be something easy. I really only want to :host a webserver. I can't even ping the public IP address. Any help :would be much appreciated. Thanks. BTW, I am able to browse the web :with the webserver.

:public IP: 60.33.23.132 :static IP: 192.168.1.17

:PIX Version 6.3(3)

:access-list 100 permit icmp any any echo-reply :access-list 100 permit icmp any any time-exceeded :access-list 100 permit icmp any any unreachable :access-list 100 permit tcp any host 60.33.23.132 eq www

:access-list inside_access_in permit ip any any

:access-list inbound permit icmp any any :access-list inbound permit tcp any host 60.33.23.132 eq www :access-list inbound permit tcp any host 60.33.23.132 eq domain :access-list inbound permit udp any host 60.33.23.132 eq domain

:ip address outside 60.33.23.50 255.255.255.248

The public IP you list as serving, 60.33.23.132, does not fall within the outside IP address range. That is NOT a fatal problem, but it does mean that you should arrange to have your WAN router

:ip address inside 192.168.1.1 255.255.255.0

:global (outside) 1 interface :nat (inside) 1 0.0.0.0 0.0.0.0 0 0 :static (inside,outside) 60.33.23.132 192.168.1.17 netmask 255.255.255.255 0 0

That statement is fine, and it will enable the proxy arp I mentioned above. The PIX *will* proxy arp for IPs that are not in the IP range assigned to its outside interface.

:access-group inbound in interface outside

That is not wrong, but notice you are not using access-list 100 at all.

:access-group inside_access_in in interface inside

That is not wrong, but since you permit ip any any in that ACL, you are doing what the PIX would do by default if you had no access-group in interface inside at all: allow all inside- originated packets to go outside.

:route outside 0.0.0.0 0.0.0.0 60.33.23.134 1

That's a bit problematic as 60.33.23.134 is not within the IP range of our outside interface. The PIX is not going to know what the appropriate mask is to use in order to ARP for that IP, so it is going to fall back upon the old "Class A / Class B / Class C" rules, and thus assume that 60.33.23.134 is part of the Class A network 60/8 with broadcast IP 60.255.255.255 .

Your ACLs and static's look okay, but your routing is questionable.

Thanks, I think you're putting me on the right track. It's got to be the router. Now, I just gotta look up how to ip forward to the firewall interface. Thanks for the boost!

Cisco deny that this is the case in fact, and claim that there are no security vulnerabilities affecting 6.3(3) of the type that you mention (and no free upgrade path to 6.3(4)).

Do you have the URL of a Field Notice or other cisco.com URL reference concerning the above?

:> 6.3(3) has some security problems. You can get a free upgrade to :> 6.3(4) even if you do not have a support contract.

:Cisco deny that this is the case in fact, and claim that there are :no security vulnerabilities affecting 6.3(3) of the type that you :mention (and no free upgrade path to 6.3(4)).

:Do you have the URL of a Field Notice or other cisco.com URL reference :concerning the above?

"Cisco has made free software available to address these vulnerabilities."

The 6.3(4)120 rebuild mentioned there is available at the special area

Many thanks. I have provided this information to Cisco by email, who hopefully will now provide the free upgrade.