Re: Establishing a site-to-site ipsec connection
From: Nico Kadel-Garcia (nkadel_at_verizon.net)
Date: 05/01/03
- Next message: John SMith: "Re: Establishing a site-to-site ipsec connection"
- Previous message: Jeff Umbach: "Re: Performing NAT on a bridge"
- In reply to: John SMith: "Re: Establishing a site-to-site ipsec connection"
- Next in thread: John SMith: "Re: Establishing a site-to-site ipsec connection"
- Reply: John SMith: "Re: Establishing a site-to-site ipsec connection"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 01 May 2003 04:05:44 GMT
John SMith wrote:
> Nico,
> In my opinion, FreeSwan works best for site to site VPNs - I do not use
> it for client VPNs so the passwords "shared secrets" are static for each
> connection. Thier is nothing to hack (unless they take over your tunnel
> server) since the secret is tied to the VPN end Point. Natting is not
> that unusuall in a firewalled situation - which assuradly your tunnel
> server would be doing firewalling even if you have other firewalls
> behind it. If you want to place it in a DMZ then pay for the IPs to
> subnet a routable address class and put your tunnel server on the DMZ
> without NAT in front of it. You would likely want to secure what
> activity is permitted over the tunnel anyway so it sould have IPTABLE
> rules.
>
> If your tunnel server is hacked than you have bigger problems anyway.
> Why steal the secrets and attempt difficult man in the middle atack when
> they can tcpdump you ipsec interfaces and lunch further attacks from
> that box or create thier own VPN connections as they choose? Hopefully
> you secured that box like it had the keys to your Porsche inside Which
> means you log everything off to a logging server, build a custom kernel,
> strip it of anything usefull, and implement change management tools and
> procedures).
It's not the tunnel server I'm deeply worried about. It's the traveling
clients.
> -the configurations are usually site specific - but the tunnell server
> would have to have a routable internet address bound to it. - Why use a
> NAT hardware solution anyway when you can have a software firewall/NAT,
> and VPN solution that can adapt to your environment with more flexibility?
Because I only want VPN occasionally. In a home network, the user often
has a NAT to share a cable modem, and wants to be able to plug in their
laptop for normal internet use most of the time and occasional VPN
access by enabling the VPN software on request.
I have no desire to teach, say, 150 corporate users to handoil-massage
full-blown VPN/NAT linux boxes in their homes. I'm happy to slap Linksys
NAT boxes into their standard home configurations, set up Linux or
Windows laptops for them, and allow some VPN access with those boxes
because I'm the one who has to deal them inside the company when they
bring them in anyway.
Keeping passwords on-line, unencrypted, is a very bad idea for any
software. It's particularly bad for client software, but even on servers
that can be expected to be monitored and checked, it's not a good idea.
> FreeSwan is an industrial grade IPSEC solution - All IPSEC
> implementations are not NAT friendly because NAT does not support
> protocal 57 (IPSEC) unless they stray from the RFC specs. Some vendors
> will wrap IPSEC in TCP to get around this for client access - those
> vendors usually are not for free and that is not standard IPSEC.
>
> Try POPTOP for Mobile users - it is a bit more friendly to NAT because
> it uses PPTP (but better implementation than MS).
I've been trying, and already submitted a set of RedHat patches to
various PPTP tools. It also keeps the passwords in unencrypted local
format on the client. I really fail to understand why any of these
softwares' clients keep that data in local files *as a default behavior*.
>> Unfortunately, too many users want to use the same password for their
>> user account as for their VPN. And keeping it in clear text on the
>> client is *begging* for it to be stolen by anyone with physical access
>> to the box. So once the client is hacked, the attackers now have VPN
>> access to your internal network.
And you've entirely failed to address this point. I'm startled that you
don't seem to take the problem seriously. What's the point in having a
VPN if you emblazon the passwords in a known location on the client
machines?
- Next message: John SMith: "Re: Establishing a site-to-site ipsec connection"
- Previous message: Jeff Umbach: "Re: Performing NAT on a bridge"
- In reply to: John SMith: "Re: Establishing a site-to-site ipsec connection"
- Next in thread: John SMith: "Re: Establishing a site-to-site ipsec connection"
- Reply: John SMith: "Re: Establishing a site-to-site ipsec connection"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
