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
(text/plain)