12-08-2010 02:51 PM - edited 03-11-2019 12:20 PM
This pix was working. I came in one morning and had no outside access.
I started to play with settings and now have managed to screw things up worse but I cant spot the problem.
Clients behind the pix cannot ping or access the internet, nor can the pix itself ping its outside subnet neighbors or gateway (default route).
The wan connection and default route IP works with another spare router with no problems.
Any comments are appreciated. Thanks !
PIX Version 6.3(1)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password sadfsa343 encrypted
passwd 34234rewer encrypted
hostname office
domain-name office.local
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol icmp error
fixup protocol ils 389
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
names
access-list 102 permit icmp any any
access-list 102 permit ip 192.168.6.0 255.255.255.0 192.168.8.0 255.255.255.0
access-list 103 permit ip any any
access-list NoNAT permit ip 192.168.8.0 255.255.255.0 192.168.6.0 255.255.255.0
access-list NoNAT permit ip any any
pager lines 24
logging on
mtu outside 1500
mtu inside 1500
ip address outside 1.1.2.3 255.255.255.248
ip address inside 192.168.8.254 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
pdm location 192.168.1.0 255.255.255.0 outside
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list NoNAT
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
access-group 103 in interface outside
route outside 0.0.0.0 0.0.0.0 1.1.2.1 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 RADIUS protocol radius
aaa-server LOCAL protocol local
http server enable
http 192.168.8.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
crypto ipsec transform-set otherend esp-3des esp-sha-hmac
crypto map home 10 ipsec-isakmp
crypto map home 10 match address NoNAT
crypto map home 10 set pfs group5
crypto map home 10 set peer 2.2.3.3
crypto map home 10 set transform-set otherend
crypto map home 10 set security-association lifetime seconds 86400 kilobytes 4608000
crypto map home interface outside
isakmp enable outside
isakmp key ******** address 2.2.3.3 netmask 255.255.255.255
isakmp identity address
isakmp policy 1 authentication pre-share
isakmp policy 1 encryption 3des
isakmp policy 1 hash sha
isakmp policy 1 group 2
isakmp policy 1 lifetime 86400
telnet 192.168.8.0 255.255.255.0 inside
telnet timeout 15
ssh 0.0.0.0 0.0.0.0 outside
ssh 0.0.0.0 0.0.0.0 inside
ssh timeout 15
console timeout 0
dhcpd address 192.168.8.160-192.168.8.210 inside
dhcpd dns 192.168.8.252
dhcpd wins 192.168.8.252
dhcpd lease 3600
dhcpd ping_timeout 100
dhcpd domain office.local
dhcpd auto_config outside
dhcpd enable inside
terminal width 80
Solved! Go to Solution.
12-09-2010 02:36 PM
Hi,
1)get rid of this and you'll solve problem 1
access-list NoNAT permit ip any any
because you are nat exempting all traffic including the one from inside to internet but you should just exempt your vpn traffic
2)
access-list 102 permit icmp any any
access-list 102 permit ip 192.168.6.0 255.255.255.0 192.168.8.0 255.255.255.0
where is it applied? if you leave first line only then apply to outside in you should solve 2nd problem
Regards.
Alain
12-09-2010 12:04 PM
Hi,
If you have console access to the PIX you can check several things...
Make sure that the internal computers can PING the inside IP of the PIX.
Make sure the cable that connects the outside interface is properly connected (maybe try a different one), that the interface shows up state (green light)...
After checking the PIX responds on its interfaces, we can check traffic through-the-box.
Federico.
12-09-2010 01:17 PM
thanks for the reply.
i can ping the pix internally and telnet/ssh, etc with no problems.
the outside interface cable has been swapped out twice just to be sure and the link light is green
(the same patch cables also work when used elsewhere, for example on my laptop)
the pix wan interface is plugged into a switch which allows us to use our block of IPs on multiple devices
other devices on this "dmz" switch are working. we have tried a different switch and different ports on those switches.
we have verified the subnet and gateway (other devices with public IPs using the same subnet and gateway are working)
i thought maybe my tired eyes were missing something silly
thanks again,
12-09-2010 01:41 PM
Of but from the PIX itself you should PING the next layer 3 device out the outside interface.
Do you see the MAC in the ARP table? ''sh arp''
Federico.
12-09-2010 02:36 PM
Hi,
1)get rid of this and you'll solve problem 1
access-list NoNAT permit ip any any
because you are nat exempting all traffic including the one from inside to internet but you should just exempt your vpn traffic
2)
access-list 102 permit icmp any any
access-list 102 permit ip 192.168.6.0 255.255.255.0 192.168.8.0 255.255.255.0
where is it applied? if you leave first line only then apply to outside in you should solve 2nd problem
Regards.
Alain
12-09-2010 05:13 PM
thanks to both of you !
the 1) suggestion by Alain is what restored service
thank you very much
i redid the ICMP stuff and ping is working as well
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