Anything wrong with this Pix 501 config?

[zcude]

Then why can't it pass internet traffic!!! Long story, short I had the Pix running its basic nat/global "I pass all traffic from inside to outside" config running without any problem. Well I did have a bit of a hard time actually getting the traffic to pass, but hey it's a PIX it normally does what it wants for the first couple of hours of installation. Finally go it to pass traffic and everything was kosher until I started configing it to VPN into my 3005 concentrator (that's a whole nother story). I got the VPN up and running fine, but now the Pix has decided to STOP passing traffic to anything other than my remote VPN site. I know it's up because I'm telnetting into it via another Cisco router on its local network, but it can't ping nothing and using the "debug icmp trace" command yields nada. Nothing. Zip. Silence. Makes me think that something is broke.

Anyways, here's the sterilized config if you guys would be so gracious to glance over and see if I have made any egregious errors. Thanks in advance.

BTW I'm about to add another VPN tunnel so that's why there is 2 entries in the nat 0 command and a second access-list.

Enjoy.

PIX Version 6.1(3)

nameif ethernet0 outside security0

nameif ethernet1 inside security100

enable password hackmewhatdoIcare

passwd itsareallyhardone ;-)

hostname Pix

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 100 permit ip 172.16.x.0 255.255.255.0 172.16.y.0 255.255.255.0

access-list 100 permit ip 172.16.x.0 255.255.255.0 10.z.0.0 255.255.255.0

access-list 120 permit ip 172.16.x.0 255.255.255.0 172.16.y.0 255.255.255.0

access-list 130 permit ip 172.16.x.0 255.255.255.0 10.z.0.0 255.255.255.0

pager lines 24

interface ethernet0 10baset

interface ethernet1 10full

mtu outside 1200

mtu inside 1500

ip address outside dhcp setroute

ip address inside 172.16.x.254 255.255.255.0

ip audit info action alarm

ip audit attack action alarm

pdm history enable

arp timeout 14400

global (outside) 1 interface

nat (inside) 0 access-list 100

nat (inside) 1 172.16.x.0 255.255.255.0 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 si

p 0:30:00 sip_media 0:02:00

timeout uauth 0:05:00 absolute

aaa-server TACACS+ protocol tacacs+

aaa-server RADIUS protocol radius

no snmp-server location

no snmp-server contact

snmp-server community public

no snmp-server enable traps

no floodguard enable

sysopt connection permit-ipsec

no sysopt route dnat

crypto ipsec transform-set myset esp-3des esp-md5-hmac

crypto map IPSEC 10 ipsec-isakmp

crypto map IPSEC 10 match address 120

crypto map IPSEC 10 set peer 206.a.a.a

crypto map IPSEC 10 set transform-set myset

crypto map IPSEC interface outside

isakmp enable outside

isakmp key ******** address 206.a.a.a netmask 255.255.255.255

isakmp identity address

isakmp policy 10 authentication pre-share

isakmp policy 10 encryption 3des

isakmp policy 10 hash md5

isakmp policy 10 group 2

isakmp policy 10 lifetime 28800

telnet 172.16.x.0 255.255.255.0 inside

telnet 172.16.y.0 255.255.255.0 inside

telnet timeout 15

ssh timeout 5

terminal width 80

I'm stumped, are you?

[gfullage]

Yep. Config looks OK from what I can tell. When you try and go out, what does a "sho xlate" and "sho conn" show? Do you see the connection created in the PIX syslog? Syslog should give you an idea of what's going on.

[zcude]

Yes to all of the above. I can see the connections in sh conn, and I can see the translations in sh xlate. The log show the connections being setup and torn down, but nothing is shown coming in. And it still blows my mind that I am passing IPSEC traffic, but when it comes to plain old ICMP or unenc IP traffic it doesn't go through. The only anamoly I've seen so far is an entry in the log when I try and ping the outside int from a remote site. Here's the error:

402106: Rec'd packet not an IPSEC packet. (ip) dest_addr= , src_addr

= , prot= icmp

Also I have setup an acces-list saying permit icmp any any eq echo/echo-r but am showing no "hits" when I try and send pings out. TAC says that no hits are showing up because I'm not getting any replys back, but it is an any any so shouldn't it show outgoing traffic as well?

Remember the days of nice simple Frame Relay?

Zach

[mike-greene]

Zach,

If you break the VPN does the PIX start passing traffic again? If so, make sure your not sending any mode config from the 3005. Did you setup the VPN through the LANtoLAN configuration on the 3005 or use the base group or a new group?

Just trying to help....

[zcude]

I set it up LAN 2 LAN. Have a network list in the source field on the 3005 of 172.16.y.0 and that 10.z.0.0 network. I'm having it shipped back to me so I can hit it with a hammer and upgrade it to version 6.2. I'll let you know if it solves anything. At least the VPN config will be simpler with the EasyVPN commands.

Need all the help I can get...

[gfullage]

The ACl is only applied INbound on the interface, so no, you won't see hits as the ICMP packets go out cause those packets don't get checked against the ACL, only the replies will.

If you're trying to ping thru the PIX, then keep in mndthat ICMP's aren't automatically allowed back in, so you'll need the following (I think you have this but just want to make sure):

> access-list inbound permit icmp any any

> accessgroup inbound in interface outside

You can make the ACL more specific by putting "echo-reply" on the end of it, that'll only allow pings responses in, so outside people can't ping your internl hosts.

The "rec'd packet not an IPSec packet" is normal, you can't telnet to the outside of a PIXunless you come in over a tunnel, so if you just try a normal telnet the PIX expects it to be encrypted and complains about it, it's nothing to worry about.

As for why unencrypted traffic doesn't go out, not sure. If the xlate/conn are created then the PIX seems to be doing it's job. You might want to check with your ISP and make sure everything there is fine, sounds like a routing issue or something like that. When the conn's are torn down, is it due to inactivity, do they show any bytes have gone across them?