WRV200: it would be great if it supported certificates for IPsec authentication

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by HughR, Jan 27, 2007.

  1. HughR

    HughR LI Guru Member

    It looks as if the new firmware will support loadable X.509 certificates for SSL authentication, at least for QuickVPN.

    Once there is some x.509 certificate infrastructure, it should be easier to add support certificate-based authentication to IPsec. The original open source code (Openswan) does support x.509, so it should be a small step.

    If anyone has the ear of Linksys, would they please suggest this? Thanks.

    Why would this be useful?

    Preshared key authentication (the only authentication currently supported (contrary to the manual)) does not scale well.

    Unless you can distinguish identities based on IP address, or use Aggressive Mode for Phase I, all peers must use the same preshared key. This means that you cannot have policies that treat peers differently. In this day and age, many systems don't have static IP addresses so distinguishing based on IP address is impractical (even if it did work, it would be a maintenance nightmare for a VPN with more than a few gateways). Aggressive Mode is known to be insecure and should not be used.

    [I admit that different PSKs could be used, with the authentication trying each of them until one worked. That scales badly and was not implemented in FreeS/WAN (I would have been the one to implement it, and I didn't). I don't think that it would have been added to the WRV200 version of the code.]

    Distributing a preshared key is significantly more difficult than distributing a certificate (or bare public key, but that is another topic). Certificates use a public-key cryptosystem so you can just publish the certificate. The preshared key must be kept secret, and yet distributed.

    On top of that key rollover (replacing old keys with new) is a nightmare with PSKs because it must be done simultaneously at all sharing sites. Key rollover is a necessary part of cryptographic hygiene.

    Summary: there are good technical reasons to support x.509 authentication in IPsec, the underlying code (Openswan) supports it, new infrastructure adds certificate management to the WRV200, so it looks like a no-brainer.
  2. DocLarge

    DocLarge Super Moderator Staff Member Member

    Firmware 1.0.26 has certificate support for quickvpn, or are you speaking of something else?

  3. ghost_zero5

    ghost_zero5 LI Guru Member

    He means certificates for IPSec-Tunnels... Which indeed would be good...
    In that case you would also probably need to support the MODE_CFG-Switch...
  4. HughR

    HughR LI Guru Member


    I'm not interested in QuickVPN because:
    • it is Linksys-only (I only have one Linksys IPsec device and a lot of non-Linksys ones)
    • the QuickVPN front-end does not run on my machines as far as I know (Linux)
    • the QuickVPN protocol has not been made public for security auditing (I am convinced that it was insecure and may still be, but the point remains even if it happened to be secure)

    This brings up another question: is QuickVPN supported in my router in a way that might reduce security, even if I don't use it? Can I disable it?

    (If I sound ignorant about the WRV200, it is because I haven't used it yet. I bought it over 6 months ago based on the fact that the manual described RSA Signature Authentication. It turns out the the firmware doesn't support this and Linksys subsequently said that they don't plan to support it (the underlying code does, just not the GUI). Furthermore, the firmware bugs described at this site make using the device unattractive. I keep hoping for either the firmware to get good enough or someone to pioneer an open rebuild of the firmware.)
    I wasn't thinking that. Can you explain your thinking?
  5. DocLarge

    DocLarge Super Moderator Staff Member Member

    Quickvpn will not lessen the security of your network, nor is it as insecure as it was made out to be. If someone wanted to actually jack a quickvpn session, they'd "literally" have to camped out at an exact location at an exact moment they knew you were going to be initiating a connection. Even then it's a "next to none" chance they'll actually get any information.

    Unfortunately, as mentioned, there's going to be no RSA functionality on this router. As much as a great device the wrv200 is , the hardware is not going to allow alot of improving :(

  6. HughR

    HughR LI Guru Member

    Thanks for the quick reply.

    I don't understand the quoted paragraph. What hardware limitation are you talking about?

    RSA is already being done to handle SSL. All I'm asking for is that the code to handle it in IPsec Phase 1 authentication be turned on and that the GUI be augmented to support configuring it.

    RSA can be done purely in software. That is the normal way for low-intensity applications. RSA is only used to check a hash, not for bulk encryption or decryption. The code to do it is in FreeS/WAN and Openswan.

    I can imagine two relevant hardware limitations: power of CPU (the WRV200's CPU is good enough) and memory for the code (most of the space is in libgmp, the GNU MulitiPrecision arithmetic library). libgmp is probably already there to handle SSL (I'm not sure).

    [I wander off to look in the GPL code for WRV200 firmware version 1.0.20, the latest I have at hand.]

    Huh. The code for RSA signatures is already compiled into the firmware. So the only thing necessary to make it functional is change to the GUI. Of course without testing, I could be mistaken.

    I did an nm on WRV200_v1.0.20.tgz:WRV200_1_0_20_GPL.tar.gz:WRV200_060103/user/openswan-2.4.5dr3/programs/pluto/ipsec_doi.o and saw (among other things):
    0000000000009ad0 t RSA_check_signature
    U __gmpz_clear
    U __gmpz_powm
    U _gp_disp
    This shows that the RSA_check_signature code is compiled in and that libgmp is being linked in.
  7. HughR

    HughR LI Guru Member

    As I said, I don't want to use QuickVPN. Given that, I'm loath to have it because any extra features add potential security problems. I'd like to turn it off because there is no upside and potential downside.

    I don't even want to have to figure it out well enough to understand any potential weakness. I must say that having one fixed private key for all systems shows a distinct lack of understanding of security. In the face of such greivous behaviour, it is hard to justify my ignoring unused features.

    Security is always more difficult in the face of complexity. If the complexity is serving no purpose, get rid of it. In the context of my use of the WRV200, that means that I want to be able to turn off any facility for QuickVPN.
  8. ifican

    ifican Network Guru Member

    You will not beable to turn it off via the gui interface. I suppose if you wanted to sure no one could take a run at your router via quickvpn you could forward port 443 and 60443 to an internal ip that is being used for anything. Other then that until someone takes on the challenge to write 3rd party code and give the gui a command line there isnt much else you can do.
  9. ghost_zero5

    ghost_zero5 LI Guru Member

    Doesn't matter: I had some problem with the WRV200 not supporting that switch but it was a more client specific problem (wrong configuration) than a problem from the WRV200...
    And also: I mixed it up with the certificates. It normallly is needed - as far as I know - for user-authentication for IPSec (XAuth and other things for this)...

    I also don't get this because after all v1.0.26 beta the QuickVPN-Part already supports not only Certificates but also creation of certificates and https is supported as well (even for management), so there shouldn't be any problem with using certificates for IPSec too, especially because the support is laready there... And also: I believe "DH-Group 18: 8192bits" should be more troublesome for the device than some certificates...

    Well: As long as you have no users (or at least no active users) it might be listening but shouldn't make anything...
    Btw.: With forwarding Port 443 to a certain PC you will run into trouble with https-websites (because that is the port https is using by default)...
  10. DocLarge

    DocLarge Super Moderator Staff Member Member

    What I'm saying, in no specific terms, is that "the hardware" (i.e., the board itself) which was made by GEMTEK appears to be a hastily built item and no matter what's being done by Linksys to make it (wrv200) functional, the level of full functionality for this device is almost becoming a pipe dream :(

    Still, the beta team will keep testing until we can say the wrv200 has met our expectations...

  11. ghost_zero5

    ghost_zero5 LI Guru Member

    Well: The only real thing I want currently is that the FTP/VoiP/ICQ/AIM-Bug gets fixed... Otherwise I didn't have any big troubles with v1.0.26 (with v1.0.24 I had troubles with DPD)...
  12. tobias.b

    tobias.b LI Guru Member

    I wonder if I'm the only one having trouble with the WLAN part. Even after fresh factory reset, the 2 devices I tried (Nokia E70 and my HP nx6325 laptop with integrated Broadcom WLAN) were able to connect and get an IP address from the DHCP server, but after that: no traffic possible, ie. a simple PING from the notebook to the router or any other computer on the network always just went into the nirvana (and vice versa ... tried WPA, WEP and unsecured connections).

    WLAN did work with 1.0.13 which was originally installed ... with 1.0.24 and 1.0.26 - no go (unfortunately using 1.0.13 doesn't really do the trick for me due to other shortcomings).

    And there are tons of other issues, like:

    1) an IPsec-passthrough connection dying after 1+ hrs and not being able to be reestablished unless the PPPoE-Connection is dropped and connected again (maybe doing some other stuff helps as well, but that's the only solution that I've found so far apart from resetting the router).

    2) the DDNS page showing "DDNS is enabled" together with the current IP address ... while the dyndns.org DNS record still shows the IP of the last connection (which I just found happening half an hour ago)

    3) or not being able to establish gateway-2-gateway IPsec connections (both gateways have dynamic IPs) using aggressive mode with Netgear's FVS318 or Billion's 7402 simply due to the fact that you can't define a the "local secure id" which is transmitted (instead always the IPV4 id with the current WAN IP address is transmitted, which doesn't do it for the other routers ... both connect fine to each other, BTW, since both allow to manually assign which ID is to be presented to the other side of the tunnel) ...

    4) and even in main mode, sometimes after a while a connection can't be renewed with the log saying something like "Can't authenticate: no preshared key found for `' and `'. " ... saving the IPsec tunnel definition without changing anything does the trick here, I'm quite sure because of the following happening in that case:

    145 [Sun 21:46:06] forgetting secrets
    146 [Sun 21:46:06] loading secrets from "/etc/ipsec.secrets"

    Sometimes (but not always) just hitting the "Restart" button does this as well.

    5) I'm running a on a local /22 subnet ( to ... but it's only possible to enter /24 addresses (192.168.4.x) for "Port Forwarding" or as the Syslog server ... even though I'm sure technically there's no reason for that, it's just a matter of the setup page which only allows to modify the class C part of the IP. Both the Billion and the Netgear routers allow to enter a complete IP address and that's definately the way to go for a router which has "business series" on the label.

    6) More to list the more I think about it ... :thumbdown:

    To be honest, in the current stage this is definately the most unstable and crippled router I've ever seen, and I was one of the first to buy a FVS318 if you know what I mean. Comparing the first FVS318 firmware releases with the WRV200 ones is like comparing WinXP SP2 with Windows 95 ... which is a real shame because if everything which is supposed to be working really would work, this would be one of the best routers (little) money can buy.

    Having said this, I understand that there are some people involved here who participate in the development of the firmware ... if there's any way I can help to get rid off the problems I've mentioned - just give me a yell.

    The most important part for me is the IPsec-passthrough-tunnel dying ... because of that I've currently got to use a 2nd router parallel to the WRV200 and use it to establish another PPPoE connection just for the IPsec-passthrough-tunnel.

    Ciao, Tobias
  13. ghost_zero5

    ghost_zero5 LI Guru Member

    At least I believe with the WRT54G I had a better W-LAN-Signal-Strength so that should be examined too...
    With DPD and v12.0.26 I can't say that I have IPSec-Tunnel-Problems... BUT OK: I only need to use DHCP for WAN...
    Well: Sind v1.0.20 or something you can use the device but the firmware that was on the device at the beginning was damn crap. I yesterday (friend got the same router but don't need that much functions) nearly wasn't able to upgrade the router because I didn't get a stable connection THROUGH LAN-Cable (not W-LAN). After disabling W-LAN I was at least able to upgrade the router BUT disabling the W-LAN-Part was not that easy...
  14. HughR

    HughR LI Guru Member

    The last few messages in this thread seem to be misplaced. I think that they ought to go into "WRV200 (What Are The Problems So Far?)" or even their own threads.

    Putting them here might cause them to be missed.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice