01-20-2009 11:15 AM - edited 03-11-2019 07:39 AM
After a power cycle our pix quit passing traffic from clients being the firewall to the internet though nothing had changed. I can ping addresses from the pix CLI, but not from any workstation. I have reset the 501 back to factory default and manually reapplied the config. I have also upgraded to 6.3(5), but no luck. Here is my config, any help would be appreciated.
PIX Version 6.3(5)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password xxx
passwd xxx
hostname pixfirewall
domain-name comtechspec.local
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 inbound permit tcp any any eq https
access-list inbound permit tcp any any eq smtp
access-list inbound permit tcp any any eq pptp
access-list inbound permit gre any any
access-list inbound permit tcp any any eq 4125
access-list inbound permit tcp any any eq 3389
pager lines 24
mtu outside 1500
mtu inside 1500
ip address outside x.x.x.x 255.255.255.252
ip address inside x.x.x.x 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
pdm location x.x.x.x 255.255.255.0 inside
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) tcp interface 4125 x.x.x.x 4125 netmask 255.255.255.255 0 0
static (inside,outside) tcp interface https x.x.x.x https netmask 255.255.255.255 0 0
static (inside,outside) tcp interface pptp x.x.x.x pptp netmask 255.255.255.255 0 0
static (inside,outside) tcp interface smtp x.x.x.x smtp netmask 255.255.255.255 0 0
static (inside,outside) tcp interface 3389 x.x.x.x 3389 netmask 255.255.255.255 0 0
access-group inbound in interface outside
route outside 0.0.0.0 0.0.0.0 70.63.67.217 1
timeout xlate 0:05:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 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 TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
http server enable
http x.x.x.x 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
telnet timeout 5
ssh 0.0.0.0 0.0.0.0 inside
ssh timeout 5
console timeout 0
dhcpd auto_config outside
terminal width 80
Cryptochecksum:xxx
: end
pixfirewall#
01-20-2009 11:41 AM
Try enabling logging and see what it generates.
01-20-2009 11:55 AM
Have you just tried ping or have you tried something else because ping will not respond as you are not allowing this in your acl on the outside interface -
access-list inbound permit tcp any any eq https
access-list inbound permit tcp any any eq smtp
access-list inbound permit tcp any any eq pptp
access-list inbound permit gre any any
access-list inbound permit tcp any any eq 4125
access-list inbound permit tcp any any eq 3389
there is no ICMP inspection on version 6.x. What happens if you try to connect to a web page ?
Jon
01-20-2009 12:20 PM
I am not sure about ICMP inspection, but when I try and connect to the web on a client I get page cannot be displayed. I cannot get DNS resolution either from our public DNS server. It seems like every piece of traffic is not being permitted outbound.
If someone could post how to enable logging so I do not have to look it up, that would be great!
01-20-2009 12:29 PM
First try just connecting to an IP address from your browser -
http://198.133.219.25 <-- this is Cisco's web site
Then if still no joy you could try debugging packets but be aware this could place a heavy load on the pix. But by the sounds of it it isn't working correctly anyway at the moment.
debug packet inside dst 198.133.219.25
debug packet outside dst 198.133.219.25
then try to connect. You should see packets hitting the inside interface of the pix with a src IP address of the client and a destination of 198.133.219.25.
You should also then see packets leaving the outside interface with a src IP of the pix outside interface and the destination of 198.133.219.25.
Let me know how you get on. To turn off debugging
no debug all
sh debug <-- if there is still debugging on repeat with
no debug all
Jon
01-20-2009 12:27 PM
I will enable logging and use a program like Kiwisyslog to see the live logging.
Do you have any output with sh xlate?
I will aslo remove the ACL and test it without the ACL.
Did you check your edge router if any?
01-20-2009 12:29 PM
logging on
logging timestamps
logging trap info
logging host inside x.x.x.x
01-22-2009 07:22 PM
Guys
Appreciate all your help. I tried debug (which I could not interpret) and logging, but it would not log any information concern http traffic. What I did figure out was that I could hit a site via IP, but not name. So I removed and re-added the fixup protocol DNS. I think that is what ultimately did it. I also added some access-lists to the inside interface, but I ended up removing them.
Thanks again.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide