Static command kills internal servers

[rtefft]

I've recently recieved a PIX515E Version 6.1 and am currently trying to get it to replace our aging Raptor Firewall. Everything works fine except I have 3 webservers that the outside world needs access too. According to Cisco's documentation I'd would have to use static's and acl's or conduit's to accomplish this. However the moment I enter in the static command for one of the servers the server's connection to the outside world dies. These are NT4.0 servers running IIS4.0. To add misery to the problem I have a test 2000 server with IIS5.0 that works absolutely fine.

Example:

NT4.0 webserver at internal address: 192.168.45.49

Before entering the static command it's able to browse the web fine through the pix.

Enter:

static (inside,outside) xx.xxx.xxx.195 192.168.45.49
access-list acl_out permit tcp host xx.xxx.xxx.195 eq www
access-group acl_out in interface outside

and it's connection through the pix is absolutely dead and the external IP address doesn't work. Also if I go on a internal workstation and try to hit the webserver at it's internal ip, 192.168.45.49, I get redirected to the xx.xxx.xxx.195

I obviously have something screwy going on or my understanding of this is completely off. Conduit's make absolutely no difference.

Config file:

PIX Version 6.1(3)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
hostname pixfirewall
domain-name xxxxxxxx
fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 1720
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol sip 5060
fixup protocol skinny 2000
names
access-list acl_out permit tcp any host xx.xxx.xxx.195 eq www
pager lines 24
logging on
logging buffered debugging
logging trap errors
logging history errors
interface ethernet0 auto
interface ethernet1 auto
mtu outside 1500
mtu inside 1500
ip address outside xx.xxx.xxx.194 255.0.0.0
ip address inside 192.168.45.1 255.255.255.0
ip verify reverse-path interface outside
ip audit info action alarm
ip audit attack action alarm
arp timeout 14400
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) xx.xxx.xxx.195 192.168.45.49 netmask 255.255.255.255 0 0
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
http server enable
http 192.168.45.80 255.255.255.255 inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt noproxyarp inside
no sysopt route dnat
telnet 192.168.45.80 255.255.255.255 inside
telnet timeout 5
ssh timeout 5
terminal width 80 ____________________________
Rich Tefft
PL/SQL Programmer

 

[Adr3nalin]

Hi, probably you have not setup (or change) the ip gateway of the NT4 box, to point to the PIX internal interface.

 

probably this command cause the problem too

global (outside) 1 interface

 

[yizhar]

HI.

ip address outside xx.xxx.xxx.194 255.0.0.0

Are you using registered "legal" ip addresses on the outside?
Is your router doing nat?
Is the xx.xxx.xxx.195 address a legitimic one? Is it routed by ISP to your pix? Isn't it by any chance a network broadcast address (if the router uses a different subnet mask then you are using, it might be the case).

Try to switch the usage of xxx.194 and xxx.195 between the pix own outside interface and the static and acess-list commands.

After you change ip addresses, with commands like "global" "static" "ip address" and other, you need to issue the command:
clear xlate
at the pix, and also you might need to clear the ARP cache or reboot the neighbor router.

The config you've posted isn't complete. Did you ommit the access-group and route statements?

Bye
Yizhar Hurwitz

http://come.to/yizhar

http://teachers.sivan.co.il/yizhar

 

[mheianna]

I don't see your defaul route in your pix. You must have a defaul route pointing to your ISP's route. Add the route :
route outside 0.0.0.0 0.0.0.0 xxx.xxx.xxx.xxx (router's ip address)

The problem that I see is that probably your internal workstation has an External DNS, so when you try to browse your

http://WWW server,

the workstation Query the ip address to the DNS and then the DNS response with the public address. The solution would be an Internal DNS.

Regards

 

[gbiello]

Another thing. You do not have the correct subnet-mask on your outside interface. You have 255.0.0.0. 255.255.255.248 would be more realistic. Regardless, your ISP will tell you what it is.
-gbiello

 

[kork]

I read in another post that clearing the ARP cache in the default gateway cleared the problem. I'm having the exact same problem, but have not tried the ARP trick yet.

Kelly