Spaced Out

Discussion in 'Tomato Firmware' started by krasnal, May 11, 2013.

  1. krasnal

    krasnal Serious Server Member

    I have an Asus RT-N16 on which I was running Shibby 102 with an OpenVPN client configured to send all traffic through to a VPN service provider.

    All has worked fine, with rock-solid stability, but I wanted to create a VPN tunnel to my nearby office, so, after some research, concluded that it should be possible to set up the router to act as a VPN server, with the office initiating the connection as an OpenVPN client.

    The only problem is that it's not possible in Shibby builds. The problem is lack of NVRAM space (32KB in the case of the RT-N16) and the large size of the OpenVPN keys and certificates. For the server side, the file sizes are:

    ca.crt is 1359 bytes
    server.crt is 4069 bytes
    server.key is 916 byte
    db1024.pem is 245 bytes

    The client side files are also very large. Long story short, could not squeeze client and server onto the RT-N16 under shibby 102.

    The original Shibby 102 USB/VPN build left 11.34KB free after a fresh install, so I tried Shibby MiniVPN (without USB) and that gave 12.66KB free after a new install, which was still too little.

    Toastman 7500.2 RT-VPN gives 15.10KB free NVRAM after a fresh install and that was JUST big enough to get all the client and server configuration details into the router. However, after setting up a few other very basic things, like WiF, DHCPi and changing the router's IP address, I'm down to 228 bytes. That doesn't give me much scope for further configuration changes.

    The bottom line is that the large OpenVPN key and certificate sizes are a crying out for some kind of compression before being stored in NVRAM. Right now, it's simply not possible for me to run even a "miniVPN" Shibby build if I want to have both a client and server configured, simply because of insufficient NVRAM space. Toastman's build is just about hanging in there but I'm reluctant to do any more changes in case I use up my remaining 228 bytes of free space.

    Can anyone comment on whether compression of selected NVRAM parameters is feasible?
  2. philess

    philess Networkin' Nut Member

    Do what i did on a RT-N16, move all the OpenVPN certificates from NVRAM to your /opt storage.

    Leave all the cert fields in the WebUI empty, instead put this in the custom OpenVPN config:
    ca /opt/certs/openvpn_ca.crt
    cert /opt/certs/openvpn_server.crt
    key /opt/certs/openvpn_server.key
    dh /opt/certs/openvpn_dh.pem
    tls-auth /opt/certs/openvpn_ta.key
    key-direction 0
    Adjust the path & filenames of course. tls-auth only if you are using it.
    By the way, i am using Victek mod on RT-N16 with about 30% free NVRAM
    without any problems, including OpenVPN server.
  3. krasnal

    krasnal Serious Server Member

    Brilliant! Many thanks philess. I wasn't aware of this method.

    Looks like I'll need to (re)install a version with USB support. No ta.key in my case.
  4. krasnal

    krasnal Serious Server Member

    philess, I decided to give Victek 9013 a spin. Since I am familiar with configuring the client side of the VPN, I thought it would be plain sailing to use your suggestion. Not so.

    Maybe this is a quirk of my VPN provider, but I could not get the connection to work with the reference to an external tls-auth file. (The other three files work successfully from /opt, BTW.) Although the system log shows the message: "Control Channel Authentication: using '/opt/OpenVPN/client/ta.key' as a OpenVPN static key file", the connection would time out. Moving the tls-auth key to the GUI box and the connection works. It's a bit weird but I've still saved a load of NVRAM space by offloading the other three files to external memory.
  5. jerrm

    jerrm Network Guru Member

    The problem with compression is the nvram tools all are text oriented, if you compress using gzip and then use the setfile functions to save to nvram you end up with an escaped mess of an entry that is probably twice the size of the original key.

    Even if you could store the raw binary data, you would not get much savings. The keys themselves don't compress very well. Compression depends on repeating patterns, and the keys are intentionally random. A 20% reduction would be doing really, really, really well - average would probably be closer to 10%. It would not be anywhere close to the 40%+ normally seen with gzip.

    With the RT-N16, you should have plenty of room to use JFFS if you want to avoid USB.
    philess likes this.
  6. krasnal

    krasnal Serious Server Member

    FWIW, I did a few tests on the biggest file, the server.crt, prior to posting and file sizes using gzip, 7zip and Winzip went from 4069 bytes to around 2100-2200 bytes. Of course, these were true binary compressed files, not escaped text. Clearly, if nvram tools only deal in printable characters, then useful compression is not going to be possible.
  7. philess

    philess Networkin' Nut Member

    If you do use tls-auth you need the additional line "key-direction 0" in the custom config too,
    it is the equivalent to selecting "Extra HMAC Authorization, Incoming (0)".

    Post more of your log if it still doesnt work. And make sure that you dont have
    a old key set in nvram.
  8. krasnal

    krasnal Serious Server Member

    No luck, philess. Yer's the log:
    It just hangs and times out at this point.

    And, to be complete, here is the custom configuration:
    [UPDATE] Cracked it. Key-direction 1 works. This is for a VPN client, so I'm guessing that 0 is for the server side and 1 for the client side.
  9. philess

    philess Networkin' Nut Member

    Oh my bad! I assumed you were doing all this on the server. Yes, it has to be 0 (=Incoming) and 1 (=Outgoing).

    You can get rid of the warning in the log and improve security a bit by doing "chmod +400" on the certificates (warning, is accessible by others). But its not required.
  10. krasnal

    krasnal Serious Server Member

    I was reading about tls-auth at the OpenVPN HowTo and it mentioned
    I tried using tls-auth ta.key 1 but it had no effect since it's clear with hindsight that it was being overridden by the later key-direction 0 directive. However, that led me to try using key-direction 1, which worked. That, in turn led me to try using only tls-auth ta.key 1, without key-direction, which also works. That's saved me a further 13 bytes of my NVRAM. ;)

    So, my successful custom configuration is now:
    WRT the warnings, I did briefly try to chmod the key files but they are somehow write protected - even when the VPN client isn't running- so it went to the back-burner. I'l get around to it soon.
    philess likes this.
  11. philess

    philess Networkin' Nut Member

    Glad you got it working. Dont worry about the chmods, i hope nobody will ever get direct access to the files on your router...
  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