Re: Establishing a site-to-site ipsec connection
From: John SMith (Jsmith_at_hotlink.com)
Date: 05/01/03
- Next message: John SMith: "Re: Establishing a site-to-site ipsec connection"
- Previous message: Nico Kadel-Garcia: "Re: Establishing a site-to-site ipsec connection"
- In reply to: Nico Kadel-Garcia: "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 05:23:17 GMT
Nico,
You are on a completely different topic. Mobile VPNs. We do not do them
with IPSEC. Maybe your POPTOP adventures will enlighten us all on the
best way to do mobile VPNs.
We use poptop at some sites and find that when we use or passwords file
and our LDAP server we have better control over passwords. I wish to
investigate token authentication for poptop and if I find anything out -
that may be a good solution for you.
Again, If someone can get the secrets off the Tunnell server you got
bigger problems. Client PCs - who would want to keep anything important
on one of those things?
-John
Nico Kadel-Garcia wrote:
> 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: Nico Kadel-Garcia: "Re: Establishing a site-to-site ipsec connection"
- In reply to: Nico Kadel-Garcia: "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
|
