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

TomatoVPN on WRT54GS behind a dlink router.

Discussion in 'Tomato Firmware' started by PackRobottom, Jan 8, 2011.

  1. PackRobottom

    PackRobottom Networkin' Nut Member

    HI,

    I've been struggling with this and googling for 2 days now. Thought I'd break down and ask for directions!

    INFO:
    I have a dlink dir655 as my main router for my decently sized home network.
    I had an old WRT54GS in the closet I haven't touched in years. I decided to resurrect it and use it as a vpn server behind my main router. Right now I have the WRT54GS cabled as follows. Client port on WRT54GS to client port on my DIR655. I have tomatovpn installed. I'm able to ping the WRT54GS from all clients on the network and access the webgui. also a laptop plugged into the WRT54GS directly can get out to wan. Good so far

    My main router (dlink) is 192.168.1.1
    WRT54GS (vpnserver) is 192.168.1.200

    I've port mapped 1194 in my dlink router to 192.168.1.200.

    I've started the tomato vpnsever and set a static key. I can't connect to the tomatovpn server.

    Am I on the right track or am I going about it wrong.

    The end goal is I want to be able to connect to the WRT54GS vpnserver from my macbook pro when I'm not home. I only need the WRT54GS to handle vpn

    note: I've turned off dchp, wireless and set the WRTGS54 as a router instead of a gateway.

    Thanks for any help.
     
  2. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    What happens when you try/what errors do you get?
     
  3. PackRobottom

    PackRobottom Networkin' Nut Member

    on macbook using viscosity I get. is it because I'm trying to connect to vpn from my own lan out to wan and back in?

    This is the error.

    Connecton Failed
    the openvpn subsystem could not be started. Please see the log section...



    Options error: Parameter --pull can only be specified in TLS-mode, i.e. where --tls-server or --tls-client is also specified.

    The OpenVPN subsystem could not be started. Please check the following:
    - Check for any error messages above this notification.
    - Make sure Viscosity is not running under a File Vault protected location (put Viscosity in the Applications folder).
    - Make sure the configuration is valid. Check the connection settings for the connection using Viscosity and make sure all settings are correct.
     
  4. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Well, like it says, "pull" can only be used in TLS-mode, and you're using static key. Sounds like your client config needs some work...
     
  5. PackRobottom

    PackRobottom Networkin' Nut Member

    I got it working, moved wrt54GS to wan and I'm using the dlink as a wirelessN and gigabit switch behind it. For anyone interested dlink client port out to client port in on wrt. DHCP off and firewall off on dlink. Clients on my lan needed no configuration. Now I can connect with vpn.
     
  6. PackRobottom

    PackRobottom Networkin' Nut Member

    sgtpepper,

    I spoke too soon I have vpn working I can see and ping local lan services from another location but I can't get back out to internet. Seems like dns. Any tips on settings or port forwarding for tomatovpn

    Thanks in advance
     
  7. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Are you wanting to have your Internet traffic go over the tunnel or bypass it?
     
  8. PackRobottom

    PackRobottom Networkin' Nut Member

    sgtpepper thanks so much for the quick reply. my goal is everything thru the tunnel. Right now I can browse lan clients and shares etc from a remote connection (by ip only), just no internet traffic back out (my goal for safe browsing remotely). I've tried using ips to get a webpage so I'm not positive it's dns. In my firewall I have a port mapped for 1194 to the router ip.

    Here is my setup

    client config:

    #-- Config Auto Generated By Viscosity --#

    #viscosity startonopen false
    #viscosity dhcp true
    #viscosity dnssupport true
    #viscosity name HomeVPN
    #viscosity ipv6 false
    route-gateway 192.168.1.1
    remote myiphere 1194 udp
    persist-key
    comp-lzo adaptive
    redirect-gateway def1
    nobind
    persist-tun
    secret secret.key
    dev tap
    dhcp-option DNS 192.168.1.1


    here is my tomato settings

    [​IMG]

    [​IMG]


    let me know if you need my firewall settings I have nat loopback on forward only should it be set to all?
     
  9. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    It's most likely a routing problem. Can you post the routing table from both the router and your client when the tunnel is connected?

    NAT loopback == "forward only" is fine.

    Just to be clear, you previously said you moved the TomatoVPN router to in front of your other router. If it is still directly attached to the Internet (no other NAT/firewall between it and your upstream connection), then no manual port forwarding is necessary.

    By the way, TAP+Static Key may be the simplest combination to setup and understand, but it is the most troublesome combination to deal with. Things should work, so don't go switching just because of this statement, but if you're not too invested in this setup you might want to consider changing to TLS. It takes a couple extra minutes to generate keys/certs, but it creates a much more maintainable setup. I typically like TUN better than TAP as well, but for a single client situation (no site-to-site), TAP should be fine.
     
  10. PackRobottom

    PackRobottom Networkin' Nut Member

    sgtpepper thanks,

    yes tomato vpn is is connected to wan. The dlink is just a switch now plugged into a client port on the tomato router.

    here is my laptops routing table

    [​IMG]

    here is tomato (hope this is what you wanted)
    [​IMG]
     
  11. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    The following lines in your routing table look wrong to me:
    Code:
    0/1        vpnserver    ... en1
    128.0/1    vpnserver    ... en1
    Those correctly say to use the VPN server for Internet traffic, but incorrectly say it can find the VPN server on the ethernet device, not over the VPN tunnel. I would think it should have tap0 instead of en1.

    Unfortunately, I don't know anything about Viscosity or MacOS to tell you where to look to correct that. It's possible that MacOS corrects for this mistake automatically and it isn't the issue, but it looks like a Viscosity bug to me.

    If you don't want to dig into that, maybe you could try switching from Static Key to TLS? The timing would be different so I could see how it could work around such a bug. Even if you end up with the same issue, at least you have a more manageable setup. :smile:
     
  12. PackRobottom

    PackRobottom Networkin' Nut Member

    anyone else have any ideas?

    both static and tls have the no internet problem. I'm pretty sure it's a problem with server configuration. Do I need to have the push route-gateway 192.168.1.1 in the server configuration field of some other commands? I have complete lan connectivity (ip only) still but no internet which is a big part of why I wanted vpn in the first place :(

    I think the problem might be here

    here is routes with and without vpn running on client

    Before:

    Routing tables

    Internet:
    Destination Gateway Flags Refs Use Netif Expire
    default 192.168.0.1 UGSc 1 0 en1
    10.37.129/24 link#8 UC 2 0 vnic1
    10.37.129.2 0:1c:42:0:0:9 UHLWI 0 2 lo0
    10.37.129.255 ff:ff:ff:ff:ff:ff UHLWbI 0 6 vnic1
    10.211.55/24 link#7 UC 2 0 vnic0
    10.211.55.2 0:1c:42:0:0:8 UHLWI 0 2 lo0
    10.211.55.255 ff:ff:ff:ff:ff:ff UHLWbI 0 5 vnic0
    127 127.0.0.1 UCS 0 0 lo0
    127.0.0.1 127.0.0.1 UH 0 2313 lo0
    169.254 link#5 UCS 0 0 en1
    192.168.0 link#5 UCS 3 0 en1
    192.168.0.1 0:11:95:77:85:5e UHLWI 1 7 en1 1194
    192.168.0.100 127.0.0.1 UHS 0 0 lo0
    192.168.0.255 ff:ff:ff:ff:ff:ff UHLWbI 0 3 en1

    After:
    Routing tables

    Internet:
    Destination Gateway Flags Refs Use Netif Expire
    0/1 192.168.1.1 UGSc 1 0 en1
    default 192.168.0.1 UGSc 2 0 en1
    default 192.168.1.1 UGScI 0 0 tap0
    10.37.129/24 link#8 UC 2 0 vnic1
    10.37.129.2 0:1c:42:0:0:9 UHLWI 0 2 lo0
    10.37.129.255 ff:ff:ff:ff:ff:ff UHLWbI 0 6 vnic1
    10.211.55/24 link#7 UC 2 0 vnic0
    10.211.55.2 0:1c:42:0:0:8 UHLWI 0 2 lo0
    10.211.55.255 ff:ff:ff:ff:ff:ff UHLWbI 0 6 vnic0
    mywanadd/32 192.168.0.1 UGSc 1 0 en1
    127 127.0.0.1 UCS 0 0 lo0
    127.0.0.1 127.0.0.1 UH 2 2343 lo0
    128.0/1 192.168.1.1 UGSc 3 375 en1
    169.254 link#5 UCS 0 0 en1
    192.168.0 link#5 UCS 3 0 en1
    192.168.0.1 0:11:95:77:85:5e UHLWI 1 1 en1 1186
    192.168.0.100 127.0.0.1 UHS 0 0 lo0
    192.168.0.255 ff:ff:ff:ff:ff:ff UHLWbI 0 6 en1
    192.168.1 link#9 UCS 3 0 tap0
    192.168.1.1 0:13:10:88:8c:c9 UHLWI 29 37 tap0 1196
    192.168.1.3 0:e:35:b3:86:66 UHLWI 0 0 tap0 1190
    192.168.1.187 127.0.0.1 UHS 0 0 lo0
    192.168.1.255 ff:ff:ff:ff:ff:ff UHLWbI 0 3 tap0

    Edit" I think I fixed it by adding routedelay in client
    and some extra stuff to server config.
     
  13. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Do share. As I said, it sounded like it may be timing bug in your client, so the route delay would make sense. What did you add to the server config?
     
  14. PackRobottom

    PackRobottom Networkin' Nut Member

    sgtpepper,

    I have both tap static and tls working now with proper routing

    the key was "route-delay 10" to client config.


    what are the advantages/disadvantages of tap of tun in my instance.
     
  15. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Glad to hear it's all working properly!
    For your situation (single client, no site-to-site), there would be very little noticeable difference. TUN should have a little less overhead (though, probably so little as to be invisible) and you'd receive an IP address on a different subnet (but all of the routing between subnets would happen automatically). With TAP, you receive an IP address on the server's LAN subnet (which, in some situations, can cause complications since you're not really on the same network segment - but most of those complications arise doing site-to-site). Another difference is that TAP tunnels forward broadcast traffic and TUN tunnels don't. In some cases this is a good thing and in others it causes complications.

    If you're happy with what you have, I say you stick with it. :smile:
     

Share This Page