Alan Dayley wrote:
> Joseph Sinclair wrote (in part):
>>> ---
>>> It looks, from what I can find, as if the WRT CPU slows by about half running a single SSL-VPN tunnel (not unusual, SSL-VPN is a rather CPU-intensive solution).
>>> If you're planning to run more than 2 clients on the VPN at a time, start with the VPN in a machine between the WRT and the wired network.  The extra CPU on even a low-end machine will be far more capable of handling the SSL-VPN load than the generally overtaxed WRT CPU.
>>> In most cases, it's reasonable to expect each SSL-VPN tunnel to consume about 100-200MHz of CPU while in use.  This varies somewhat by type of CPU, but most specialized firewall systems that support SSL-VPN have accelerator cards just to handle the cryptographic overhead (and provide a hardware entropy source to stave off entropy starvation, a common problem with SSL-VPN's [and SSL in general])
>>>
>>> One other point, if you're requiring an OpenVPN connection to link through the WRT, then turn OFF WEP and WPA.  They add a lot of now-useless overhead to the WRT CPU, and they can actually compromise security of the VPN tunnel.
> 
> The performance worries me so let me go down a different path.
> 
> We have a Citrix VPN server already on the internal network.  The
> firewall directs connections from the Internet to that VPN server for
> remote access to the internal network.  The new plan would be to do the
> same on the wireless access point.
> 
> - All connections to the wireless access point, via WPA, would be routed
> to the internal VPN server.
> - If you can log into that VPN server, you are in.  If not, you go no
> further.
> 
> In other words, I would want to setup the access point such that it only
> routes to the internal VPN server and no where else.  Does that sound
> like a reasonable plan?
> 
---
This sounds like a good and viable plan, although I'd drop the WPA part.  If you're already encrypting the communications via VPN, it's both wasteful and, possibly, self-defeating to add WPA (or WEP) on top of that.  Encrypting an already encrypted datastream can actually reduce security, and is generally not recommended (it takes a lot of careful planning to ensure the two encryptions don't result in a net reduction in ciphertext entropy).  It's particularly unwise to use AES on top of AES of 3DES on 3DES, both doublings are known to result in a less secure ciphertext.


---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change  you mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss