RE: VPN Question

["Burton M. Strauss III" <BStrauss () acm org>]

You know, it sounds like the Hotel's are implementing NAT.  If you are
getting a routable IP address, then things are fine.  But, if the Hotel
implements NAT, it will be assigning addresses in the 192.168.0.0/16 (or
other RFC 1918) space.  That's the address that the IPSec(VPN) client thinks
it needs to stick into the packets and that will cause problems.

Remember, IPSec has two modes (ESP and AH and I can never keep them
straight), one mode which encapsulates the entire packet in a secure
envelope and one which just encrypts the payload, leaving the original
headers intact.

With the former, you're toast in NAT situation, because the internal address
is going to be in the RFC 1918 space.

src=192.168.1.111 dst=vpn.company.com (payload)

becomes

src=gateway.hotel.com dst=vpn.companu.com (src=192.168.1.111
dst=vpn.company.com (payload))

At your vpn gateway, that's stripped back to

src=192.168.1.111 dst=vpn.company.com (payload)

but now your vpn gateway doesn't know how to return information to
192.168.1.111


With the latter, the NAT device rewrites the address to it's own own WAN
address, so the returned packets can be delivered back to it to undo the
process.  If you're using this mode of IPsec, it should work.

src=192.168.1.111 dst=vpn.company.com (payload)

becomes

src=gateway.hotel.com dst=vpn.company.com (payload)

At your vpn gateway, it knows how to return the packet to gateway.hotel.com:

src=vpn.company.com dst=gateway.hotel.com (reply)

Whereupon the NAT device at the hotel rewrites it to:

src=vpn.company.com dst=192.168.1.111 (reply)

and everything is fine.


Now, there ARE IPSec enabled NAT routers, which handle the encrypted
payload.  But they do it by intercepting the tunnel setup request and
creating a tunnel from the client to the NATbox then from the NATbox to your
vpn gateway:

When you open the tunnel, you're told that the endpoint is 192.168.1.1, so
your packets look like this:

src=192.168.1.111 dst=192.168.1.1 (payload)

which becomes

src=gateway.hotel.com dst=192.168.1.1 (src=192.168.1.111 dst=192.168.1.1
(payload))

The IPSec enabled/NAT box strips that down to

src=192.168.1.111 dst=192.168.1.1 (payload) (it can be decrypted because
it's the tunnel endpoint)

and then it rewrites it to:

src=gateway.hotel.com dst=vpn.company.com (payload)

and stuffs it down the tunnel back to vpn.gateway.com it established at the
same time as the tunnel from 192.168.1.111->192.168.1.1 was setup:

src=gateway.hotel.com dst=vpn.company.com (src=gateway.hotel.com
dst=vpn.company.com (payload))

But those cost $$$$ and most Hotels probably just have a cheap Linksys if
they've got anything.

-----Burton

-----Original Message-----
From: DeGennaro, Gregory [mailto:Gregory_DeGennaro () csaa com]
Sent: Friday, August 22, 2003 3:32 PM
To: Jim Brezicky; security-basics () securityfocus com
Subject: RE: VPN Question


Jim,

This is a hotel issue.  If it works in some and not in others, it means in
this case that the source is the problem.  Unless you have round robin VPN
IP addresses and your users do not know what the IPs are?  Which I highly
doubt and why would you want to do this?

Regards,

Greg DeGennaro Jr., CCNP
Security Analyst


-----Original Message-----
From: Jim Brezicky [mailto:brezicky () infimed com]
Sent: Friday, August 22, 2003 10:29 AM
To: security-basics () securityfocus com
Subject: VPN Question




Good afternoon all,

This posting is a little off track, but I'm hoping someone can help me
anyway.

I have a SonicWall Pro230 and I'm trying to do VPN with it. My users
connect from some locations and not others. Example: They could connect
from the Airport in Cincinnati, but not the airport in Las Vegas. Seems
they can't connect in many (if any hotels). In speaking with SonicWall
they said this is a known issue when connecting through a firewall on the
hotel side.

I know I'm not the first company to try this, and was wondering how others
get by this issue? Or is this an inherent SonicWall issue.

Most of my users are traveling Sales people, and will go all around the
US, and Japan.

Any insight would be GREATLY appreciated.

Thanks,

Jim Brezicky
InfiMed Inc

---------------------------------------------------------------------------
----------------------------------------------------------------------------

---------------------------------------------------------------------------
Attend Black Hat Briefings & Training Federal, September 29-30 (Training),
October 1-2 (Briefings) in Tysons Corner, VA; the world's premier
technical IT security event.  Modeled after the famous Black Hat event in
Las Vegas! 6 tracks, 12 training sessions, top speakers and sponsors.
Symantec is the Diamond sponsor.  Early-bird registration ends September
6.Visit us: www.blackhat.com
----------------------------------------------------------------------------


---------------------------------------------------------------------------
Attend Black Hat Briefings & Training Federal, September 29-30 (Training), 
October 1-2 (Briefings) in Tysons Corner, VA; the world's premier 
technical IT security event.  Modeled after the famous Black Hat event in 
Las Vegas! 6 tracks, 12 training sessions, top speakers and sponsors.  
Symantec is the Diamond sponsor.  Early-bird registration ends September 6.Visit us: www.blackhat.com
----------------------------------------------------------------------------