OK, this is probably a really simple screwup. I'm new to the PIX (a 515e in this case), and it's much different than the 2611 I'm used to configuring. All I want to do is setup for a VPN Client v4. I can connect, but cannot pass traffic through the tunnel. After connection, the client can ping the PIX through the tunnel, and the PIX can ping the client through the virtual address assigned. But the client cannot access anything on the trusted network. Here's what I have:
ip local pool vpnclients x.x.17.1-x.x.17.254
access-list INSIDE permit ip x.x.55.0 255.255.255.0 any
access-list INSIDE permit icmp x.x.55.0 255.255.255.0 any
access-list OUTSIDE permit ip any x.x.55.0 255.255.255.0
access-list OUTSIDE permit ip any host x.x.193.226
access-list OUTSIDE permit icmp any x.x.55.0 255.255.255.0
access-list OUTSIDE permit icmp any host x.x.193.226
access-list VPN-NAT permit ip any x.x.17.0 255.255.255.0
I have a full class C on my trusted network, so no NAT. And yes, I know I'm wide open, but first things first. I'll tighten up the ACLs after I get the VPN running. And this is a secondary firewall anyway, so I'm not completely vulnerable.
Hmmm, actually this config looks pretty good, can't see anything obviously wrong with it. You mention that this is a secondary firewall, so does this connection go through your primary firewall, you may want to make sure it's allowing everything through. Is your VPN client behind any sort of PAT device? If so, try adding "isakmp nat-traversal" to your configuration. Also, do the internal hosts have this PIX set as their default gateway, or at least do they have a route to the x.x.17.0 subnet that points to the PIX inside interface?
Right now I'm still in testing mode; the test client is connected via a hub directly to the PIX's WAN interface. So the upstream firewall is not in this equation. And the internal hosts do have their default gateway pointing to the PIX interface. What's baffling to me is that if I tracert from the client, I can see that it going through the IPsec tunnel. I just can't get past it.
Yes, currently. My original test setup had another upstream router with the default gateway on the test client then set up for it, but when that test failed I removed it and put the test client directly on the PIX's WAN interface.
I discovered the capture command with some very interesting results. Machine A is in the protected LAN, machine B in the VPN client. I setup a capture on the WAN port to capture all traffic to/from machine B. My first test was a ping from A to B. Without the tunnel to test the capture I get:
1) PIX is placing the ping echo request on the wire unexcrypted. Why isn't the traffic using the established tunnel?
2) I see no correlated evidence of a reply from the VPN client, either encrypted of not.
3) The client is setup for UDP transparent tunneling. So why the protocol 50 traffic? I thought that was the point of transparent tunneling, to get past the ISPs like earthlink who block protocol 50 traffic.
So next I run the same capture while pinging from the VPN client (B) to the inside network host (A).
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...