1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Tomato 1.21+OpenVPN GUI mod - CCD problems

Discussion in 'Tomato Firmware' started by sunjon, Oct 21, 2008.

  1. sunjon

    sunjon Network Guru Member

    Tomato 1.21+OpenVPN GUI mod - CCD problems(SOLVED)

    I first mentioned the problem of client config dir in the GUI mods original thread, but I`m starting a new thread for clarity.

    I've already taken the following steps to try to resolve the issue.
    • Edited the server config to remove the default 'duplicate-cn' entry, which would have caused CCD not to work.
    • Ensured that the client-config-dir and ifconfig-pool-persist parameters both used full paths. I tried with /etc/openvpn/CCD and /jffs/CCD, both with the correct read/write permissions.

    ipp.txt is never populated, and the ifconfig-push and iroute parameters in /CCD/<user> are never applied.

    I mentioned that I'd seen someone else reporting similar problems with Roadkill's GUI'less version:

    Can anyone confirm they've had it working?

    Edit: (insert embaressed face here) Ack!, apologies - It wasn't working because a certain windows user wasn't paying attention to case sensitivity in path names. Client-Config-Dir is working fine (once dupicate-cn is turned off).

    I've still got a problem trying to get site-to-site with TUN interface, but at least i can rule out CCD as being part of the problem.
  2. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Great! I was looking all over for a reason why it wouldn't work. Glad to see it is.
    I finally have a remote router to test some site-to-site configurations. I'm starting with TAP, though. So, if you find some changes that get TUN site-to-site working, let me know. It'll allow the experimentation to happen in parallel, getting a build with working TAP and TUN site-to-site released sooner.

    I apologize for having site-to-site working in the initial release. I had tested it as a server and as a client, but naively thought that would mean site-to-site would work when combined. :blush:
  3. sunjon

    sunjon Network Guru Member

    A note to say I'd got TUN site-to-site working during the week. I`ll post my settings here as a guide for others.

    There are a couple of key things to do to get it working:

    • The first addresses the hardcoding of the 'duplicate-cn' parameter in the current builds config. The VPN server must have been started once for the config file to be created, and a flag must be set in NVram for this config file not to be deleted when the service is stopped:

      At the shell prompt:
      nvram set vpn_debug=1
      nvram commit  
      service vpnserver1 stop
      You can now edit the /etc/openvpn/server1.ovpn file manually, or include the following in a "fixup.sh" script to do it for you:
      grep -v duplicate-cn /etc/openvpn/server1.ovpn > /etc/openvpn/fixed.ovpn
      mv /etc/openvpn/fixed.ovpn /etc/openvpn/server1.ovpn
      Once you've finished entering all the configuration details in this post, restart the service using:
      /etc/openvpn/vpnserver1 --config /etc/openvpn/server1.ovpn
      Again, starting the VPN server like this is only necessary whilst 'duplicate-cn' is being hardcoded to the config file. If you use the web interface to start the service, your edits to the file get overwritten(though you could make it read only perhaps!).

      SgtPepperSKU is aware of this issue and this step will not be neccessary in the next released build

    • Mount JFFS or a CIFS share and create a directory named CCD within it, so you have somewhere to store your client configurations that will survive a reboot. In the CCD directory make a file whose name matches that of the Common Name used when you created your client certificate, containing the following line:
      Make Client Config files for any other VPN clients you have want to include. You can also set static VPN ips using ifconfig-push within these files(see here).

    • The rest of the config was, as with the TAP config - pretty much (once you've picked out the relevant parts) as is detailed in the sample scripts at openvpn.net.

      There was far less documentation however, on the necessary firewall rules to enable clients connected either side of the tunnel to communicate, by masquerading their source address as that of the VPN server/client. At least that's what i think they do - I just know they were needed for things to work. I don't have a great knowledge of iptables and credit for the solution goes to the author of the post by ng12345 buried in Roadkill's VPN mod's thread.

    Network Setup

    Server router IP :
    Client router IP:

    The VPN uses the range.

    Change the ips' and netmask's throughout the config according to your setup, bearing in mind that all clients(and the server) must be on different sub nets in a TUN config.


    Enter the following in the VPN Tunneling > Server > Custom configuration text box:
    ifconfig-pool-persist /jffs/ipp.txt
    # Push Tomato VPN server's LAN route to VPN clients
    push "route"
    # Push Tomato VPN client's network to OTHER clients
    #push "route"
    client-config-dir /jffs/CCD
    # Make client network known to server.
    route # route of Tomato VPN client's network

    VPN Client

    Enter the following in the VPN Tunneling > Client > Custom configuration text box:
    keepalive 15 60
    resolv-retry infinite
    # Require that peer certificate was signed with an explicit nsCertType
    # designation of "server"
    ns-cert-type server

    Firewall/Routing Settings

    On the VPN server router, open your to allow client connections by adding the following to Administration > Scripts > Firewall:
    iptables -I INPUT 1 -p udp  --dport 1194 -j ACCEPT
    Enter the following on both routers firewall settings, changing the net mask in the last 4 lines to match that of the router you are configuring at that time:
    #these lines allow access to the lan behind the router
    iptables -I FORWARD -i br+ -o tun+ -j ACCEPT
    iptables -I FORWARD -i tun+ -o br+ -j ACCEPT
    #allow ssh and web router administration through the tunnel
    iptables -A INPUT -i tun+ -p tcp --dport 22 -j ACCEPT
    iptables -A INPUT -i tun+ -p tcp --dport 80 -j ACCEPT
    #required for access to windows XP shares...
    iptables -t nat -A POSTROUTING -s -o br+ -j MASQUERADE
    # Masquerade local clients source address 
    # The net masks below are that of the router you are entering this config into.
    iptables -t nat -A POSTROUTING -s -o tun+ -j MASQUERADE
    iptables -A FORWARD -s -o tun+ -j ACCEPT
    iptables -A FORWARD -d -m state --state ESTABLISHED,RELATED -i tun+ -j ACCEPT
    # don't know if the last two lines are necessary
    I think that's everything, let me know if anything isn't clear.

    That's both the TAP and TUN configs I've had successfully running. The next challenge is to get Samba server running on the VPN server router. I plan to run it as a WINS server(which apparently it does by just setting a config parameter), to replace the functionality lost as a result of NetBios broadcasts not being able to work over a routed VPN.

    It's probably more appropriate in a separate thread. I downloaded the ipkg mips flavor samba-server, but it isn't a single binary with the library compiled within it and I've no idea how you'd go about using these package contents on Tomato - though I'm sure it's doable.


  4. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Note that in the newest version, none of this configuration is needed for full two-way TAP (same subnet each side) or one-way TUN (client to server) site-to-site connections. All that should be necessary to make TUN site-to-site tunnels (or TAP across distinct subnets) is the client-config-dir configuration settings sunjon described above.

Share This Page