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.
PIX Version 6.1(3)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password hackmewhatdoIcare
passwd itsareallyhardone ;-)
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
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
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.
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?
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?
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.
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?
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...