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

OpenVPN TAP Site-to-Site configuration problems

Discussion in 'Tomato Firmware' started by gijs73, Oct 11, 2010.

  1. gijs73

    gijs73 Networkin' Nut Member

    Hi, I have been unsuccessfully trying to configure the following:

    I have 3 routers all running Tomato 1.28 (K26 USB vpn3.6) They have distinct subnets of 192.168.0.x, 192.168.1.x and 192.168.2.x.
    I wish to configure a VPN server on 192.168.0.1 in UDP/TAP/TLS mode that the other two routers can connect and bi-directonally route the subnets. If I understand correctly, this will require me to bridge the networks (using push commands?) I should mention at this point that I am reluctant to go down the TUN route, although I have seen it mentioned on several occasions, as the majority of connections to the VPN server on 192.168.0.1 will be from windows clients who will benefit the visibility of samba shares from being directly attached to the network.

    Currently the VPN server is configured as follows:
    Code:
    Interface: TAP
    Protocol: UDP
    Port: 443
    Firewall: Automatic
    Authorization: TLS
    HMAC: Disabled
    Client address pool: DHCP
    Direct clients to redirect: NO
    Respond to DNS: No
    Encryption cipher: Default
    Compresson: Adaptive
    TLS Regeneration: -1
    Manage Client-Specific Options: YES
    Allow Client<->Client: YES
    Allow Only These Clients: NO
    
    In the enable table I have certificate CNs for the two router clients as follows:
    Code:
    TICK Router1 192.168.0.0 255.255.255.0 TICK
    TICK Router2 192.168.0.0 255.255.255.0 TICK
    On the client routers i have:
    Code:
    Interface: TAP
    Protocol: UDP
    Server Address/Port: my.hostname.com 433
    Firewall: Automatic
    Authorization Mode: TLS
    Extra HMAC: Disabled
    Server on same subnet: NO
    Create NAT on tunnel: currently NO, have tried YES.
    
    The windows clients running OpenVPN Gui connect fine to the server with no problems, However the routers connect and are shown in the status but I am unable to ping from client to server or vice versa.

    I would very much appreciate any assistance you could give me.
  2. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    If you have different subnets, you shouldn't use TAP. The only benefit of TAP over TUN is that it allows you to use the same subnet. Other than that, it is less efficient and can cause administration headaches.

    Further, the combination of TAP, different subnets, and bi-directionality is not possible. With TAP, you either have to have the same subnet (which isn't the case for you) or you have to create a NAT on the tunnel (which makes the tunnel initiation uni-directional).

    Your options:
    1. Place the routers on the same subnet, but using non-overlapping address ranges (administration headache)
    2. Use TUN, which will leave your clients not being able to browse to a network share using "Network Neighborhood" unless you set up a WINS server (even if you don't, they'd be able to access the shares by device IP/name).
    3. Run two VPN servers on the router, TAP and TUN. You can then have the other routers connect via the TUN server and the other clients connect via the TAP server. (would accomplish everything you want, but could place more load on the router)
    My suggestion would be 2. if you can live without "Network Neighborhood" browsing to a network computer (would still be able to browse shares within a network computer), 3. otherwise.

    Also, you said each router had their own distinct subnet, but you filled them all in as 192.168.0.0 in the client-specific router table. That won't work. You have to fill the correct values there for bi-directionality to work.
  3. gijs73

    gijs73 Networkin' Nut Member

    Many thanks for your quick reply, It looks like I shall take your advice and go for option 2 although this will require some disruption to all sites which I was trying to avoid.

    Am I right in thinking that bi-directonal routing is not possible because the vpn server is bound to its local address and that there is no interface to the other two networks?

    This said would it be possible to leave the networks but modify the subnet mask on all of them to be 255.255.0.0? that way I could then bridge them?
    Is there then a simple iptables rule I can use to block DHCP requests from remote networks?

    Im guessing its not as simple as something like this for each network:
    Code:
    iptables -I FORWARD -p udp -s 192.168.0.0 --dport 67 -j DROP
    iptables -I FORWARD -p udp -s 192.168.0.0 --dport 68 -j DROP
    sorry for all the questions, I am just trying to rule out various options!
  4. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Bi-directionality would not be possible because TAP only works across like subnets. In order to have different subnets, you'd have to create a NAT on the client so that it looks like a single device on the server subnet instead of multiple devices on a different subnet. Once you add the NAT, you lose the ability to initiate connections from the server to the client (much like devices behind your router's WAN NAT can't be directly accessed from the Internet).

    This still wouldn't accomplish what you're looking for. Browsing for computers in "Network Neighborhood" relies on broadcast messages, which only work when the subnet masks are consistent.

    I'm afraid not. iptables can't block DHCP requests. For that you'd need ebtables, which isn't in the firmware.
    No problem! I completely understand where you're coming from.

    I'd like to reiterate that network sharing works perfectly fine using TUN. You just can't open Network Neighborhood to see what computers are available. Instead you'd just have to manually type in \\<computernameorip\.

    If you set up WINS servers, I pretty sure you could lift that restriction as well (in the presence of a WINS server, I believe that Windows computers will use that instead of relying on broadcast messages).
  5. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    On second thought, you may be able to get things working with TAP if you just fix your client-specific options table (everything like you had it, except fix the subnet values in the table).

    For the site-to-site connections, I have provisions in the firmware to treat TAP like TUN when the subnets are different. This means that you can have bi-directionality, but broadcast messages still won't traverse the tunnel (meaning "Network Neighborhood" browsing to computers won't work).

    The individual client PCs should still be able to connect in bridged mode, accessing network resources as if they were directly connected.

    Sorry for my misdirection before. I guess I'm not fully awake today yet...
  6. gijs73

    gijs73 Networkin' Nut Member

    Many thanks, That clears everything up and now that the office is quiet, I have reconfigured one of the sites to use TUN and its all working beautifully. I shall need to roll out changes to the remote openvpn laptops at some point.

    Each site has its own WINS server running and I'm currently playing with my own client and it looks like I can push the remote WINS server to the clients by putting this in the server custom config:
    Code:
    push "dhcp-option WINS 192.168.0.10"
    so after I alter the ovpn files, I can implement the changes and it will be transparent to the users :)

    Super, now to appease the iPhone crowd I need to work out how to implement PPTP!
    Many thanks for your support and incredible firmware.
  7. gijs73

    gijs73 Networkin' Nut Member

    our posts just crossed, in reference to post #5, It might be handy for me to configure the network like this (at least temporarily till I get to modify all the clients) so I shall try switching back again.

    Edit:
    Ive just put it back and I get the following error message in the client log:
    Code:
    OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
    OpenVPN ROUTE: failed to parse/resolve route for host/network: 192.168.1.0
    
    Additionally, I am unable to ping from client to server or vice versa.

    Do you happen to know the correct syntax to add the route-gateway on either the client or push from the server?

    Warm regards
  8. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    The server should have pushed out a route-gateway automatically. However, I've found the "DHCP" mode of "Client address pool" to be not completely reliable (this is a fairly new feature in OpenVPN, and I'm not convinced it's bug-free). Try unchecking "DHCP" and giving an explicit address range for the clients. Or, possibly, just adding the route-gateway manually in the server custom config (or drop the push and enter it in the client config):
    Code:
    push "route-gateway 192.168.0.1"
  9. gijs73

    gijs73 Networkin' Nut Member

    With a little more digging which helped me better understand what is going on, I have managed to pinpoint why the site2site TAP configuration was not working.

    My tomatoVPN client was not being assigned an IP address from the DHCP pool, the interface was sitting in promiscuous mode but the client never managed to successfully set its ip address.

    I changed the options on the server and set a pool and now both my Windows OpenVPN GUI clients, and my TomatoVPN GUI get assigned IPs in the remote range from the pool.

    Is it possible this is a bug or is the client handling the DHCP address as expected?

    Thanks
  10. gijs73

    gijs73 Networkin' Nut Member

    Sorry, again I missed your reply, You are quite right, the DHCP mode seems to be buggy and setting a pool fixes the issue.

    This fixed my issue and everything is working as normal.

    I am now happily playing and messing up the routing tables on the client side by pushing bogus routes ;)

    Thank you SO much for your help.

    Edit:
    Just a note to add that it seems to be a bad idea to push Router1 192.168.1.0 255.255.255.0 to the client of that network - the client accepts the route and all routing stops dead!
    The correct way to set the route via the interface seems to be in Advanced/Static Routing Table and then to add the route as follows:
    Destination Gateway Subnet Metric Interface Description
    192.168.1.0 192.168.0.1 255.255.255.0 0 LAN Router1
  11. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Glad you got everything working!

    Sorry for the detour I attempted to send you on, though.

Share This Page