What's the deal with NAT?

Mullen, Matt Matt.Mullen at TEAMGDM.COM
Fri Apr 28 15:56:57 EDT 2000


Thanks for all of the replies on this.  The information has been very
helpful.  I contacted Cisco about the Altiga solution and they did say it
would require purchasing additional appliances.  I think the short term
solution might be to put those users needing VPN access on the outside of
the firewall,  and put some sort of personal firewall on their laptops for
security.   Of course, then how they will get back inside to access the
corporate LAN creates another issue.  Dialing up via modem is another
proposed solution.  Any other ideas?

Thanks,

Matt

-----Original Message-----
From: Biggerstaff, Craig [mailto:Craig.Biggerstaff at csoconline.com]
Sent: Friday, April 28, 2000 3:24 PM
To: 'Mullen, Matt'; VPN at SECURITYFOCUS.COM
Subject: RE: What's the deal with NAT?


> From: Mullen, Matt [mailto:Matt.Mullen at TEAMGDM.COM]
>
> I have been trying to connect several VPN clients to their
> respective VPN
> servers across the Internet without any success and I was wondering if
> anyone might be able to tell me the answer to this question:
> if any device
> is running NAT that is between two VPN endpoints,  will the connection
> between the two VPN endpoints fail?

...

> I have had the same problems with other VPN clients,  such as
> CiscoSecure
> VPN client and even PPTP.  None of them are able to connect when the
> firewall running NAT is in between the client and the host
> they are trying
> to reach.  I haven't tested thoroughly but I have another
> client with a
> different firewall (Cisco PIX) and it seems to be the same
> problems there as
> well.  I have heard that NAT causes problems with IPSec,  but
> could anyone
> describe what the limitations are,  i.e.  what can and what
> can't you do
> with VPNs and NAT?

An IPSec "tunnel mode" VPN does its magic by completely encapsulating the
outbound source packet, headers and all, in a new IP packet.  The new IP
packet's source address is the outbound address of the VPN device, and its
destination address is the inbound address of the VPN device at the other
end.  Using the IPSec ESP method, the packet contents (in this case, the
original packet) are encrypted, and both encrypted contents and new headers
are signed with a hash value appended to the packet.

Why this bothers NAT is the last part:  a NAT device in the middle will
rewrite the new source address with one of its own choosing.  The VPN device
at the other end will verify the integrity of the incoming packet by
computing its own hash value, and will complain that the hash value appended
to the received packet doesn't match.  The VPN device at the other end
doesn't know about the NAT in the middle, so it assumes that the data has
been altered for nefarious purposes.

Hope this clears it up a bit.  I can't step through PPTP in the same detail
without looking at a book, but I would expect a similar problem.




-- Craig Biggerstaff
craig at blkbox.com

VPN is sponsored by SecurityFocus.COM




More information about the VPN mailing list