Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Multiple Cisco IPSec VPN clients behind a NAT firewall 3

Status
Not open for further replies.

lgarner

IS-IT--Management
Jan 26, 2002
2,348
US
I've seem a similar message or two here and I'll try not to rehash the issue, but I could use some advice from someone who's actually solved the problem (or knows that it can't be done.)

I have a Pix 515 configured for a site-site VPN with another office. I am using the same Pix for client-site VPN connections (I know, no access to the other office- not a problem). I cannot make multiple client VPN connections to the Pix from behind a NAT firewall (DLink and Linksys tried so far). The second connection disconnects the first.

I've seen a reference to NAT-T, but am not clear on what it accomplishes or if it will have an effect on the site-site VPN.

I'd like to know first, is there a setting on the Pix which can overcome this problem or, if not, is there a NAT firewall which can be used by the clients?

Thanks.
 
*think* must write an faq on this sometime */thinks*

I'll try to do the cut down version, i usually ramble for too long about this. IpSec vpns require ESP traffic to flow. ESP is a portless protocol (in the same way that tcp or udp is a protocol, it's protocol number 50)

Because it's portless NAT routers (firewalls etc, any NAT device) don't know how to translate it from the local address to the public address properly. Most cheap new-ish routers incorporate a feature they call "IpSec pass-thru". This effectively notes which internal machine first initiates IpSec (read ESP) traffic, then re-routes any incoming ESP traffic back to that local machine.

As you can see, this presents a problem if two or more local machines try to make a vpn connection - all the ESP traffic is routed back to the first machine, which discards anything which isn't relevant to it. So the second machine can't connect.

To solve this a new standard was developed, NAT-t, whereby ESP traffic is encapsulated inside UDP traffic, under UDP port 4500.

For this to work both ends of the vpn tunnel must support NAT-t.

Cisco VPN client since *at least* 3.6.3 supports NAT-T. Cisco PIX since 6.3 supports nat-t, but requires an additional line added to the PIX config, which turns on NAT-t when required for all vpn tunnels on the pix (this is not a security risk, so can be safely turned on if you think you *might* need it) In your case you do.

The pix command is below;

isakmp nat-traversal

Be sure to upgrade the pix o/s to 6.3 beforehand, preferably to 6.3(3)

Cheers

Chico

CCNA, MCSE, Cisco Firewall specialist, VPN specialist, wannabe CCSP ;)
 
Thanks, chicocouk!!! I must buy a Cisco PIX!!
 
Very clear explanation. The one part that I wasn't clear on and want to be *sure* of is the nat-traversal on the Pix, "which turns on NAT-t when required for all vpn tunnels".

If I turn on nat-t on a Pix which has a tunnel to another Pix, is it necessary to enable nat-t on the other Pix as well? This is important, since the Pix being used for client vpn has a tunnel to another Pix, which has a tunnel to yet another. If enabling nat-t on one will disrupt the tunnels, I'll have to be very careful in planning the change.

Thanks again.
 
Enabling nat-t will not affect your existing tunnels at all. But you will need it turned on at both ends of the vpn tunnel for it to work, you can't turn it on at one end only. So put the command into both pix.

What happens is that during the phase 1 negotiations, the pix will send out Nat-D packets (nat-traversal discovery) which are used to establish 1) whether there are any nat devices between the two tunnel endpoints (between the two pix) and 2) whether the other tunnel endpoint (pix) supports Nat-t.

If the other pix doesn't support nat-t, then the first pix simply won't use it. Similarly, even if both pix support nat-t, if the nat-d packets show there are no nat devices between the two pix, they won't use Nat-t either, because they don't need to.

So really, you're in a win-win situation. The pix negotiate and decide whether they can, and whether they need to use nat-t or not, and if they do they will, if not, they won't.

Great new feature, made my life so much easier.

CCNA, MCSE, Cisco Firewall specialist, VPN specialist, wannabe CCSP ;)
 
lgarner,

I think my explanation maybe didn't answer your question very well, so to be more specific, in your situation you can do this;

Enable nat-t on the cisco vpn client (in the properties of the connection entry)

Enter the isakmp nat-traversal command on the one single pix that you connect to using the vpn client.

You *don't* need to configure the other pix to use nat-traversal, their existing site-to-site vpns will continue working exactly as before.

Hope that's a bit clearer

:)

CCNA, MCSE, Cisco Firewall specialist, VPN specialist, wannabe CCSP ;)
 
Perfect! Thanks for the info. I'll set it up later today.
 
Just to follow up, it worked like a charm. Thanks again.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top