Passing VPN session through PIX fails after ISAKMP

[rgralnik]

I am trying to get my PIX 501 v6.3(1) to allow an IPSec VPN session to be established from a PC running a VPN client to a server on the net. For

this thread, I'll ID my inside net as 192.168.1.0

and the outside as 10.10.10.0/24. I have played with

a variety of access-lists including:

access-list 10 permit udp 10.10.10.0 255.255.255.0 host 192.168.1.1 eq isakmp

access-list 10 permit esp 10.10.10.0 255.255.255.0 host 192.168.1.1

access-list 10 permit ah 10.10.10.0 255.255.255.0 host 192.168.1.1

and their inbound equivalents. I even tried

access-list 10 permit ip 10.10.10.0 255.255.255.0 host 192.168.1.1

I applied these to both to the outside interface with

access-group 10 in interface outside

I even tried applying it to the inside interface.

I also tried applying access-list's for PC->Server

as one set to one interface and for Server->PC as

a separate set to the other interface.

The hitcnt rarely went above 0 on show access-list

for any of these ACE's even though I watched the

traffic flow in both directions with "debug packet

..." on the PIX and using ethereal on the PC to

sniff the packets.

I added

protocol fixup esp-ike

but it didn't help.

After all of this I'm still seeing traffic back and

forth during the ISAKMP handshake (UDP port 500),

but as soon as the session cuts over to protocol 50

there is no inbound traffic from the VPN server.

I talked to the server admins who assure me my user

authentication information is valid and the server

is up and running. I talked to the ISP, which assures me they are not blocking IP protocol 50

(apparently Comcast was doing that so I checked).

The TACS guy suggested adding the fixup protocol but

hasn't figured out a solution either.

I'm wide open to suggestions.

Thanks in advance.

Richard

[rgralnik]

Just a correction of a typo and one note of explanation:

The fixup line should have read "fixup protocol esp-ike" of course.

If you're wondering why the VPN server's address is shown as a subnet with a mask in the access-list

instead of as a host, it's because there are multiple servers in the same address range and

I didn't want to have to keep changing the ACE's each time the server admin's suggested I try a

different one, or if the PC client cycled to a different server on the next invocation.

Richard

[apriore685]

Not exactly sure of the problem, but sounds somewhat similiar to one I had. Try this command.

isakmp nat-traversal 20

Anthony

[tvanginneken]

Hi,

like Richard already told you, you need to enable the esp-ike fixup protocol to allow vpnclient connections through the pix firewall:

'fixup protocol esp-ike'

Be aware of the fact that once you enable this fixup protocol, you will not be able to termination vpntunnels (client-to-site or site-to-site) at the pix anymore.

Kind Regards,

Tom

[bhillman]

There was a paper about this a while back. You could configure the PIX to allow the client from the inisde to establish a VPN by allowing ipsec (50)? and gre and tcp 1739 from the remote server to the nat'd address of your pc through the PIX and this doesn't break your other VPN functionality.

[rgralnik]

I found a link on cisco.com for "Configuring an IPSec Tunnel through a Firewall with NAT" that might be what you're referring to (http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a008009486e.shtml).

I think it predates the fixup protocol because I've been told to remove the access-list commands when I added "fixup protocol esp-ike".

I'm not sure how opening the ports for gre and webaccess will do in this case. I've never heard

that either one is involved in a configuration like

this.

I also updated my PIX to 6.3(3). No joy there

either. This is becoming a real puzzle.

Richard