How does this config work?

[Paul Cardon]

I'm correcting myself...  Ughh

Paul Cardon wrote:
> 
> > Looking at the PIX example on the HOW-TO page, I'm not sure if this
> > example is for my scenario or for a situation where clients connect to
> > a VPN gateway located behind the PIX. In either scenario, I can
> > understand why I would need the conduit for ESP, but why is it that a
> > conduit for UDP/ISAKMP is required? Shouldn't the PIX take care of
> > setting up a state entry for outgoing destination udp/500 so that only
> > source udp/500 packets from the peer in question can come back?

The conduit is only for inbound connections and would be needed for both
IKE and ESP.  In your scenario, where you are going outbound, it isn't
used for any of the protocols.

> The PIX does what you are describing as far as keeping state entries but
> your client is doing ESP in UDP encapsulation so that the ESP can
> survive NAT.  It must also do UDP encapsulation on the ISAKMP.  The
> association is being created for the original ESP packet not the
> encapsulated ESP.  The original ISAKMP packet also needs to be preserved
> so that IP addresses and such in the IKE and ESP packets match.  The
> Cisco client works this way.

I also blew it on this part.  The IKE on UDP port 500 is not further
encapsulated in UDP to traverse a NAT device.  That's what I get for
scanning the draft document instead of re-reading that part carefully
before responding.

In any case, AH, ESP tunnel, and ESP transport can all be made to
survive NAT using UDP encapsulation as described in the draft document.

-paul

VPN is sponsored by SecurityFocus.com