Solved: Re: PAT/NAT and VPN through a PIX

rj.remien · ‎04-29-2003

"PPTP through the PIX with Port Address Translation (PAT) does not work because there is no concept of ports in GRE" - This is an excerpt from a PIX config about version 6.2 and below.

1. How was this fixed in 6.3? Is GRE encapsulated in udp or tcp to use ports to track the connection?

2. Does "fixup protocol esp-ike" use the same technology - the source port created by the IKE? - ISAKMP cannot be enabled when using this command

3. What about "isakmp nat-traversal"? How is this different from fixup protocol esp-ike"

Thanks,

RJ

gfullage · ‎04-29-2003

1. When the PIX sees outgoing PPTP (TCP port 1723) packets it now opens up holes for these to return, as well as opening a hole for the GRE packets, it never did this before. The TCP PPTP packets can be PAT'd fine since they're TCP packets. The GRE packets I believe, are tracked by the unique tunnel id field in the packet.

2. It uses the source port of the ISAKMP packet for the ESP packets as well. The current limitation is that if you have this enabled, you can't use the PIX to terminate IPSec sessions, hence you can't turn ISAKMP on on any interface. You can also have only one internal IPSec client use this feature.

3. NAT-T is a new standard for IPSec peers to work through a NAT device, in that they'll detect the address changes during the tunnel negotiation and automatically encapsulate the packets in UDP 4500. Turning this on enables the PIX and the other device (if it supports it) to automatically detect a NAT/PAT device in between them. This differs from "fixup esp-ike" in that the PIX is not actually terminating the IPSec tunnel with esp-ike, but it is the termination point in nat-t.

View solution in original post

gfullage · ‎04-29-2003

1. When the PIX sees outgoing PPTP (TCP port 1723) packets it now opens up holes for these to return, as well as opening a hole for the GRE packets, it never did this before. The TCP PPTP packets can be PAT'd fine since they're TCP packets. The GRE packets I believe, are tracked by the unique tunnel id field in the packet.

2. It uses the source port of the ISAKMP packet for the ESP packets as well. The current limitation is that if you have this enabled, you can't use the PIX to terminate IPSec sessions, hence you can't turn ISAKMP on on any interface. You can also have only one internal IPSec client use this feature.

3. NAT-T is a new standard for IPSec peers to work through a NAT device, in that they'll detect the address changes during the tunnel negotiation and automatically encapsulate the packets in UDP 4500. Turning this on enables the PIX and the other device (if it supports it) to automatically detect a NAT/PAT device in between them. This differs from "fixup esp-ike" in that the PIX is not actually terminating the IPSec tunnel with esp-ike, but it is the termination point in nat-t.

rj.remien · ‎04-29-2003

Glenn,

Once again, thanks for the knowledge transfer. As I continue to implement more PIX firewalls at client sites, I like to have a thorough understanding of all the features. I enjoy your lucid explanations.

RJ