PAT for IPSec connections

In article , Jo Knight wrote: :What ports do I need to 'forward' from the edge routers in order for :ISAKMP and IPsec to work correctly.

You always need udp 500 (isakmp) to start the session.

If you do not have Nat-Traversal active, then you need IP *protocol* 50 (ESP). This is not a port and cannot be handled through port forwarding. If NAT-T is not enabled but you have NAT, then you cannot use AH so you don't have to worry about IP protocol 51 (AH).

If you do have NAT-T active, then after the initial UDP 500 handshake, a short negotiation will be attempted that involved UDP 4500 in both directions. If the negotiation detects that NAT is taking place, then a dynamic UDP port will be allocated, and the ESP (and AH) will be encapsulated inside that, with no Protocol 50 or Protocol 51 needed. NAT-T *is* compatable with PAT. [Note: the port is dynamic on each end, and permission for it will be opened automatically.]

The intermediate pre-standard Cisco NAT-T mechanism used UDP 10000 instead of UDP 4500.

Thanks for that Walter.

So if I have NAT-T disabled I cannot achieve what I want due to not being able to forward the ESP protocol?

I will turn on NAT-T and see how I get on forwarding the ports you mentioned.

Jo

In article , jo wrote: :So if I have NAT-T disabled I cannot achieve what I want due to not being :able to forward the ESP protocol?

No, if you have NAT-T disabled, you cannot achieve what you want to do because you are looking at the problem the wrong way.

You don't -need- multiple external IPs on your VPN concentrator. What you -need- is a way so that when a packet comes in from a particular one of your SDSL lines, that the reply will go back to the same SDSL line. And that's a routing matter, rather than a an IPSec matter.

If your clients have distinct IP address ranges, then you can solve the problem by simply using static routes pointing to the appropriate serial interface on your routers.

If your clients do not have distinct IP address ranges, then there are techniques you can use that involve NAT -- NAT the

*source* IP address of the incoming packets. Then when the reply comes back from your concentrator, de-NAT back to the original IP.

Hmm, this is getting complicated :)

I see what your saying now, the problem I have is that the clients will be coming from unknown IP addresses (connecting via the Cisco VPN client).

So if I, say, give client A an address for the concentrator that comes in on SDSL 1 I would have to NAT their incoming address on the interface it comes in on, so the concentrator sees it as something else and when it replies the router will translate the address back to the original address.

I dont suppose you have any idea as to the command used for this, or at least point me in the direction. Will I need to do policy based routing or NAT to accomplish this?

Thanks again! Jo

In article , jo wrote: :So if I, say, give client A an address for the concentrator that comes in on :SDSL 1 I would have to NAT their incoming address on the interface it comes :in on, so the concentrator sees it as something else and when it replies the :router will translate the address back to the original address.

Exactly.

:I dont suppose you have any idea as to the command used for this, or at :least point me in the direction. Will I need to do policy based routing or :NAT to accomplish this?

I believe it would be something like ip nat outside source