[CentOS] regarding vpn server for 1500 clients

[Robert Moskowitz]

Les Mikesell wrote:
> Robert Moskowitz wrote:
>   
>>>> I have never liked the SSLvpn architecture.  Never really liked the SSL 
>>>> handshake; just too chatty.  I wear my biases quite plainly on my arm 
>>>> sleeve (I chaired the IPsec workgroup during the time the RFCs came 
>>>> out).  You want security, go with IPsec.  Even ESP NULL gives you per 
>>>> packet authentication and thus proof of server and client.  Just pay the 
>>>> price for IKE, which I never liked.  Part of the reason I invented HIP....
>>>>     
>>>>         
>>> But ssl vpns work though just about any firewall/proxy/nat that already 
>>> permit https.  Traversing those can be painful or impossible for ipsec.
>>>       
>> The problem is NATs (so speaks a co-author of RFC 1918!). SSL vpns 
>> tunnel networking over Transport. Gee I wonder why that works through NATs?
>>     
>
> Or, given the near-universal use of NATs, you have to wonder about the 
> viability of anything that doesn't traverse them gracefully.
>
>   
>> Part of the NAT traversal mess contributed to my drive for HIP which the 
>> actual developers realized needed a different ESP mode: BEET. Of course 
>> even HIP needs ICE to find things out there and to be found....
>>     
>
> I'm not sure what any of those acronyms means, 

For HIP (Host Identity Protocol) check out RFCs 4423 adn 5202 - 5207.

For BEET (Bound End to End Transport), it is an Internet Draft: 
www.ietf.org/*internet*-*draft*s/*draft*-nikander-esp-*beet*-mode-09.txt


ESP has challenges going through a NAT as the outer IP addresses of the 
tunnel are bound to the Security Association. With BEET, that is 
removed, the outer IP addresses are not used in calcuating the 
authentication. More differences than that, but in a nutshell...

BEET is now part of the 2.6.27 kernel. I want to finish some testing 
then get a bug report into Redhat to get them to add it to the 2.6.18 
kernel for RHEL/Centos 5.
> but the other problem 
> with IPsec is that the usual tools don't provide an interface for 
> routing and they need some other mechanism to decide what goes through 
> them.

This has always been my issue with IPsec tunnels. What to use and do you 
know if what you want secured is? Thus the policy always is all or 
nothing; very broken per the RFC. FreeSWAN tried doing it better, but 
kind of sputtered out (Hugh really wanted to do it right). This was thus 
another issue I had with tunnel mode over transport that led to BEET mode.

> On Ciscos I've always set up GRE tunnels to get something the 
> routing protocols can see, then crypto-mapped the GRE packets.  Is there 
> a common computer implementation that would mesh with this?
>   

No. At least that I know of.