Site-to-Site OpenVPN with NAT using 2 tomato routers

Discussion in 'Tomato Firmware' started by Dutch87, Apr 22, 2018.

  1. Dutch87

    Dutch87 Addicted to LI Member

    Hey everyone, so, after lots of googeling and trying I'm turning to you guy's.

    My situation is that I have two Netgear R7000's running Tomato 1.40 Shibby (ARM) AIO buids..

    My test setup is as following (later the other router is going to ship to another location):

    MODEM DHCP: 192.168.0.x

    Tomato-A:
    -WAN IP: 192.168.0.101
    -LAN DHCP: 192.168.1.101-192.168.1.199
    -OpenVPN server IP: 10.8.0.0

    Server settings:
    -Push LAN to clients: yes
    -Direct clients to redirect Internet traffic: yes
    -Respond to DNS: yes
    -Advertise DNS to clients: yes
    -Cypher: AES-256-CBC
    -Compression: Adaptive
    -Manage Client-Specific Options: yes
    -Allow Client<->Client: yes
    -Allow Only These Clients: enable, commonname, 192.168.2.0, 255.255.255.0, push yes
    -Allow User/Pass Auth: no

    Firewall Script: (sorry guys, no idea here, just copied)
    iptables -A FORWARD -i br0 -o tun21 -j ACCEPT

    Tomato-B
    -WAN IP: 192.168.0.102
    -LAN DHCP: 192.168.2.1-192.168.2.99
    -OpenVPN client IP: 10.8.0.6

    Client settings
    -Redirect Internet traffic: yes
    -Accept DNS configuration: exclusive
    -Cypher: AES-256-CBC
    -Compression: Adaptive
    -Verify server certificate (tls-remote): no

    Firewall Script: (sorry guys, no idea here, just copied)
    iptables -A FORWARD -i br0 -o tun11 -j ACCEPT
    iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -d 192.168.2.0/24 -j SNAT --to $(nvram get lan_ipaddr)

    What is working?
    -VPN Internet
    -When using windows 10, browsing files from Site A on Site B works
    -Browsing files from B on NAS on lan A works.

    What's not working yet?
    -Steam Link
    -Steam Home streaming
    -Windows file browsing from B to A

    My goal is that:
    • All machines on B use the DNS server in router A and only use the internet of router A when VPN is active (when set dynamic DNS on A)
    • All windows machines of A and B can see eachtother (Windows filesharing, steam streaming, steam link) without having to modify the firewalls on the windows machines and other equipment (especially making steam streaming work can be challenging I suppose)

    Now as far is I have googled this needs a NAT.

    Then these tutorials are about just setting up a site-to-site VPN, but without the tailored NAT.
    http://blog.qnology.com/2013/02/tutorial-30-minutes-or-less-site-to.html
    http://steveit.ca/2017/03/06/setup-site-to-site-vpn-with-2-tomato-routers/

    Then this one talks about a NAT setting. I modified it and put it into the execute command field and did afterward nvram commit. After waiting a few minutes I was able to connect from site A to a samba share on windows 10 on site B. B to A was not working.

    http://www.linksysinfo.org/index.php?threads/site-to-site-vpn.72306/

    Then after a reboot of the client router this doenst work anymore untill I do the command again in execute command window: iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -d 192.168.2.0/24 -j SNAT --to $(nvram get lan_ipaddr)

    And then there is this tutorial: https://www.mcbsys.com/blog/2011/11/set-up-vlan-and-site-to-site-vpn-with-tomato/

    • So, can anybody please help me to make it happen and to help me understand the layers?
    • What are the right settings for this kind of setup (make shares and steam streaming work)? I have no clue what i typed in the Firewall script, maybe its counteracting?!
    • Is it possible to configure everything in GUI?
    • Can we make it survive a reboot of both routers?
    Maybe this thread can be the perfect guid to other people planning on setting something similair up.

    Thanks in advance and kind regards,

    Joeri

    P.S.
    For those people intrested to know the Site-to-Site OpenVPN speed of the R7000 using Shibby 1.40 it is as following:
    -VPN with QoS enabled: 3,46MB/s
    -VPN with QoS disabled: 4,15 MB/s
    -VPN with QoS and LZO compression disabled 4,85MB/s
    -Regular Internet Transfer speeds using light QoS (no L7 filters) is: 140 Mbs
    -Regular Internet Transfer speeds using heavy QoS (with L7 filters) is: 110 Mbs
    -Game server 17ms with QoS and 72ms without QoS with high network loads.
    I'm using a 250Mbs internet line. CPU load is 56% so I guess the firmware is singlethreded/single core.
     
    Last edited: Apr 30, 2018
  2. eibgrad

    eibgrad Network Guru Member

    It's not clear to me if the only thing not working is the persistence of the firewall rule, or something more. But if it's just making the firewall rule persistent, you need to add it to the firewall script under Administration->Scripts. Executing it under Tools->System Commands is fine for testing purposes, but it doesn't make it permanent. Only adding it to the firewall script will do that.
     
  3. Dutch87

    Dutch87 Addicted to LI Member

    Thanks for pointing that out Eibgrad! Ill try that next time!

    Well, it's just overall. It has to work both sides, so both LAN's are equal to eachother and windows filesharing and steam home streaming has to work out of the box like you are all on 192.168.1.x. I guess this config is a mix of what i found in all the links and not working at all as i wish, exept that one tine file sharing in one direction was woking after entering iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -d 192.168.2.0/24 -j SNAT --to $(nvram get lan_ipaddr).

    But I must say, I have at this point NO idea what I should do or doing when using firewall rules. Maybe one setting is counteracting another... I cannot find a proper manual on it... Also every link is showing some different settings...

    I was imagining somehouw that all the ip's from 192.168.2.1-192.168.2.99 would be translated to 192.168.1.1-291.168.1.99 and coëxcist with the 192.168.1.100-192.168.1.256 ip's on LAN A and steam and windows filesharing would not notice anything. Like at LAN A all is on 192.168.1.X and on LAN B everything looks like 192.168.2.x where 192.168.2.2. would be translated to 192.168.1.2 and 192.168.1.102 to 192.168.2.102. But thats just me dreaming...

    I imagine you guy's knowing just the thing to make it all work!?!!!
     
    Last edited: Apr 22, 2018
  4. eibgrad

    eibgrad Network Guru Member

    I'm still not sure what the problem is. You said that rule fixed the problem, but it wasn't persistent. So you can fix the persistence problem by using the firewall script. And if you want it to work both directions, just create a second rule w/ the source and destination switched. After that, what's left?

    If by "seeing" each other you mean that network discovery should work (i.e., devices on one side should see devices on the other side when using Windows Explorer or streaming services), that's problematic. Network discovery doesn't work across different ethernet segments, and each side of the tunnel represent different ethernet network segments, and by extension, IP networks.

    Perhaps you need to step back a second and explain the bigger picture. At this point all I know is a bunch of plumbing details. But I don't know the ultimate goal here. At this point, it appears this isn't even a real network, but just a proof-of-concept. I say that because of the WAN ip of each router sharing a common, local IP network (192.168.0.x). For all I know, perhaps establishing a bridged (tap) VPN where each side was using the *same* local IP network would make more sense, and you wouldn't have any of these problems (neither routing, nor network discovery).
     
    Last edited: Apr 22, 2018
  5. Dutch87

    Dutch87 Addicted to LI Member

    I'm sorry, but it's not a proof of concept. My settings are maybe a mess with counteracting/obsolete settings put in. And finally only filetransfer in one direction is possible using windows file sharing. A to B is blocked by windows firewall.

    When it works Router B will be connected to a 4G modem and moved to a remote site without landlines. Since 4G is used I need to use a VPN to obfuscate traffic. Also it's silly to travel everytime up and down to there to fix something when I can just test it at home. Why would somebody go trough the trouble of buying two tomato routers to keep both of them on the same modem? Aslo WAN = WAN, if its modem x or y should not matter.

    Also since that network will be part of my LAN and will have a separate NAS, being able to sychronise the NAS over the VPN.

    Finally, it would be great to have windows filesharing and remote desktop working with as absolute bonus the Steam link on Lan B. Now you're probrably going to say, Steam lan streaming over 4g?! Well with <50ms its possible and the best HW accelerated remote desktop option availbe.

    Then about TAP and TUN, people warn for lots of ethernet overhead and unstability. Since it will go over the GSM network with data limit, TAP might be a more preferable sollution I was told.

    My question to you/everybody is, how to make it work. To my idea there must be ton of offices that would need to be able to share subnets (not sure if thats the right term?).

    So, how would we make it work?
    And what does these rules mean?

    iptables -A FORWARD -i br0 -o tun11 -j ACCEPT

    iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -d 192.168.2.0/24 -j SNAT --to $(nvram get lan_ipaddr)
     
    Last edited: Apr 23, 2018
  6. Dutch87

    Dutch87 Addicted to LI Member

    Would you be so kind to at least help me with this, check my settings and help me with the right firewall script rules? Manny thanks in advance!
     
  7. eibgrad

    eibgrad Network Guru Member

    Note, I'm going to provide feedback over several posts since there's a lot to say here, and it's just too much for a single post.

    When configuring a site-to-site VPN, you don't normally have to be adding firewall rules like the following.

    Code:
    iptables -A FORWARD -i br0 -o tun11 -j ACCEPT
    The above rule is allowing traffic to be routed between the local IP network and the OpenVPN client's network interface. But the router is smart enough to realize this rule is necessary for the OpenVPN client to work, at all! Obviously clients on the LAN (br0) will be routed over the OpenVPN client's network interface (tun11) once the VPN is established. The router is fully aware of this and adds such rules automatically.

    99% of the time, you don't need to concern yourself w/ such things. That's the problem w/ getting knee deep in all those other threads. Many ppl make *bad* suggestions. Or perhaps are trying to solve other unrelated problems. In some cases, beginners can end up reading *too* much and get confused. And pretty soon they're *over* configuring the router.

    The following firewall rule is one of those exceptions.

    Code:
    iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -d 192.168.2.0/24 -j SNAT --to $(nvram get lan_ipaddr)
    This goes into the firewall script of the OpenVPN client.

    What it's doing is masking packets coming from 192.168.1.x (the OpenVPN server side) w/ the LAN ip of the router on the OpenVPN client side (presumably 192.168.2.1) so that other devices on 192.168.2.x will be *tricked* into thinking that the packet is coming from a device on their own local network, and thus their personal firewalls will not prevent access. Those devices on the 192.168.2.x network will then reply to the local router, which then sends the reply back to the original source IP on the 192.168.1.x network.

    It's just a clever trick to fool the target device into thinking the request came from its own local network. But it's also possible to NOT need this trick if you're willing to update the personal firewall on those Windows machines to accept the other side's local IP network! That's probably a better option for the long haul. But some ppl prefer the above "hack". They find it more convenient. But one of the problems in using such a hack is that it makes it impossible to filter which specific clients do and don't have access since every access seems to come from the local router. IOW, the hack comes at a price.

    In order to get the same effect for clients on the OpenVPN client side who need to access Windows machines the OpenVPN server side, you can use the following firewall rule (which gets added to the router on the OpenVPN server side).

    Code:
    iptables -t nat -I POSTROUTING -s 192.168.2.0/24 -d 192.168.1.0/24 -j SNAT --to $(nvram get lan_ipaddr)
    Exact same idea. Now client devices from 192.168.2.0/24 will have their source IP masked w/ the LAN ip of the router on the OpenVPN client side (presumably 192.168.1.1), thus solving the problem in the other direction.

    More to come.
     
  8. eibgrad

    eibgrad Network Guru Member

    Let's talk about the following.

    -Manage Client-Specific Options: yes
    -Allow Client<->Client: yes
    -Allow Only These Clients: enable, commonname, 192.168.2.0, 255.255.255.0, push yes

    Most likely you DON'T need the client-to-client option. What this does is allow two or more concurrent OpenVPN clients to communicate w/ each other over the same OpenVPN server. By default, each OpenVPN client connected to the same OpenVPN server is isolated from each other. It's a lot like wifi AP isolation, where wifi clients can communicate w/ each other when enabled. But if you *want* them to be able to communicate (thus using the OpenVPN server as a kind of gateway), you enable this client-to-client option.

    So based on your description, this option seems irrelevant and can be kept disabled.

    The "Allow Only These Clients" option is exactly what it appears to be. Only those OpenVPN clients w/ the specified common name are allowed to connect. But in the case of a site-to-site VPN, it takes on more significance.

    Because multiple OpenVPN clients can connect to the same OpenVPN server, and will likely (in fact, must) have *different* local IP networks behind them, the OpenVPN server needs to know *which* local IP network lies behind each of those OpenVPN clients. That's why you add those local IP networks in the Subnet and Netmask fields. Now the OpenVPN server knows which OpenVPN client to route to when any of those networks is specified as a target destination.

    Note, although 192.168.2.0 255.255.255.0 is correct for this setup (that's the local IP network behind your (presumably) one and only OpenVPN client), you don't need to *push* that network to the OpenVPN client. The OpenVPN client already knows this information (again, that's its own local network). Rather, it's the OpenVPN server that's being told what's behind the OpenVPN client. I'm assuming you're using the correct common name on the client cert as well.

    IIRC (it's been a while since I've done this), you also have to manually add the OpenVPN client's network to the Custom Config field on the OpenVPN server side using a route directive.

    Code:
    route 192.168.2.0 255.255.255.0
    The reason you add this routing information in both places is because there are two levels of routing going on here. The route directive changes the routing tables in the kernel, while the routing information in the "Allow Only These Clients" section is for the *internal* routing within the VPN.

    If you want more information about these differences, check out the following link.

    https://community.openvpn.net/openvpn/wiki/RoutedLans

    Note, it isn't necessary to fully understand the information in the above link in order to get this working. Properly configuring the GUI will just make things work correctly. But sometimes a link like the above can help clarify what's happening behind the scenes. If not now, perhaps later once you get more familiar w/ things.

    More to come.
     
  9. eibgrad

    eibgrad Network Guru Member

    Sometimes it's easier (and even advantageous) to create multiple OpenVPN connections. IOW, establish OpenVPN servers and clients on each side that connect independently. Nothing *requires* that you only use a single OpenVPN connection bi-directionally. You *could* have two uni-directional connections. I've done this myself this many times, even when a single bi-directional configuration was possible . Sometimes it's just more convenient, and offers more options.

    As far as routed (tun) vs. bridged (tap) tunnels, that decision is based on several factors. The assumption in a bridged VPN is that you have control of both sides of the VPN, since each side is sharing the same ethernet network, and by extension, same local IP network. But obviously this wouldn't be the case if say, you and a friend, decided to share resources. You each still want to maintain your own ethernet and IP networks, and security, but just access a few resources from the other. A routed VPN will suffice. The problem comes when you also need network discovery support.

    Network discovery is when your device (PC, laptop, TV, media center, etc.) scans the network looking for resources and reports what's available. That will NOT work across a routed VPN. It requires a bridged VPN.That doesn't mean those resources aren't available. You can still address them by their respective IPs. But I'm aware that there are some devices (particularly consumer devices) which will only work w/ network discovery. IOW, they don't allow direct entry of IP addresses. And in that case, there's not much you can do about it. IMO, that device is responsible for the limitation, not the VPN.
     
  10. Dutch87

    Dutch87 Addicted to LI Member

    Dear Eibgrad,

    Thank you so much for taking the time and explaining it step by step!!!

    Maybe this thread will someday show on top of all the other threads to explain this once and for all to people starting with this same idea.

    Also thank you for telling me which options are over configured.

    Edit: Then it sounds more like I need a bridged VPN, but I havnt read any manuals about it and I read it was a very bad idea to do so, especially over an unstable GSM connection.
    Is TUN the only way to make steam streaming possible? What is your advice? I indeed have full control over all the LAN's. But then again only having to set the DHCP server once sounds like a charm...
    https://community.openvpn.net/openvpn/wiki/BridgingAndRouting

    1. Is in this TUN setup all the internet traffic routered over the VPN and is only the custom DNS used of the router?
    2. The "route 192.168.2.0 255.255.255.0" command I will put in the custom config box of the server
    3. Yes, they both use the common name of the certificate and it's my only client so far. So im going to remove the push box there.
    4. So, I'm going to ajust the firewall scripts and remove the obsolete command
    5. Yes, I trust all the machines on my LAN, so I rather not reconfigure all the firewalls if its possible to do it with that "hack" NAT code.
    6. Well, I dont want to dissapoint you, but now I'm thinking about what if someone would add a 3rd tomato router as VPN client? Would you need to double the NAT commands and leave Allow Client<->Client: yes enabled? Does it matter that there will be only one set of certificates with the same common name?
    7. I guess its best to keep it simple and have laptops and cellphones on the road connect to the second VPN server or the VPN server of my NAS. In a later stage I will ask some questions how to make the filesharing work on laptops on the road connection to the secondary VPN server
    I will await your next posts!
     
    Last edited: Apr 23, 2018
  11. Dutch87

    Dutch87 Addicted to LI Member

    Hmmm, seems like I was betting on the wrong horse all along I suppose and I should go for bridge...

    1. Can both routers be on 192.168.1.X when bridged?
    2. Do I keep the advanced tab the same of the VPN server? Or do I have to remove the only allow these clients
    3. How much data consumption should be expected from the layer 2 / ethernet frames?
    4. Are there any extra firewallrules needed on the bridged setup to make everything work?
    5. And last but not least: why would they say: You have Windows server(s) you want to access and require network neighbourhood discovery to work via VPN and WINS is not an option to implement. If you have WINS, you don't want bridging. Really.
    Sorry for all the questions, but I guess the will cover the whole subject.

    Again manny thanks!
     
    Last edited: Apr 23, 2018
  12. eibgrad

    eibgrad Network Guru Member

    Network discovery and streaming are NOT synonymous. You don't need network discovery to stream. You need network discovery to *search* for resources, which may include streaming services (e.g., Plex Media Server). Once found, you have the information needed to connect to and stream content from that service. But if you know the IP address of that resource already, you can usually address it directly. No need for network discovery.

    The problem sometimes comes when a given device (usually an appliance) will *only* support the use of network discovery for connecting to that resource. IOW, it doesn't present a GUI for entering the IP address of the resource. It will only work by using network discovery to gather the info it needs to connect to resources found on its own.

    Depends on how you configure it. You can establish a VPN for the sole purpose of accessing resources only available over that VPN. In your case, the clients behind the OpenVPN client (192.168.2.x) can access devices on the network behind the OpenVPN server (192.168.1.0) because once the VPN is connected, the 192.168.1.0/24 network is pushed (at least it should be) to the OpenVPN client's routing table. Likewise, by making those routing changes on the OpenVPN server for 192.168.2.x, clients behind the OpenVPN server (192.168.1.x) can find devices on 192.168.2.x.

    IOW, once the routing information for each side is made available to the other and associated w/ the VPN, both sides can communicate. But traffic will *only* cross the VPN when the routing requires it. So if some device behind the OpenVPN client references a public IP, it's NOT going to send it over the VPN, but instead, as usual, over its own WAN. Same thing on the OpenVPN server side and the clients behind it. If you *want* the devices behind the OpenVPN client to send their internet requests over the VPN, you have to force it by either checking "Direct clients to
    redirect Internet traffic" on the OpenVPN server config, or checking "Redirect Internet traffic" on the OpenVPN client config. Your choice. Depends on which side you want to control this behavior. Whichever side, this cause the default gateway on the OpenVPN client to be changed to the VPN. And now public IPs (not just references to local IPs behind the OpenVPN server) will be routed over the VPN.

    Did a little extra checking on my own OpenVPN server (as I said, I haven't done this in quite a while, so I'm rusty). Turns out configuring the "Allow Only These Clients" option takes care of this automatically. As I said, the router is usually smart of enough to take care of obvious details, at least for basic, simple configurations.

    Note that adding the route directive won't hurt anything. It's just redundant.

    This is why it's so difficult to help ppl in this forum, esp. those new to networking. This stuff quickly gets complex. I'm not even mentioning other small details just to keep things from getting out of hand. This is the kind of thing you need to sit down over a kitchen table w/ an expert and work out exactly what it is you're trying to accomplish, the options w/ all their limitations, security issues, etc. There's only so much that can be communicated in a post like this.

    Once you start adding more than one OpenVPN client, things get more complicated. Whether you want all or some of these OpenVPN clients to communicate w/ each other is up to you. Only you can determine your requirements. But if you expect bi-directional access w/ additional OpenVPN clients, *all* of those clients will need to be using their own unique, non-overlapping local networks (192.168.2.x, 192.168.3.x, 10.10.1.x, etc.). If that wasn't the case, routing would be ambiguous.

    In addition, since each OpenVPN client is uniquely identified based on its common name, each OpenVPN client must use different common names on its certs.

    And yes, if you wanted to use the NAT trick, you'd have to duplicate it across each OpenVPN.

    As I said, as you make the config more complex, other considerations come into play. When using a single OpenVPN client, nobody worries about the fact you've only established one cert. But once you decide to support multiple clients, you're now in the business of generating multiple certs, one for each OpenVPN client. At least if you want site-to-site w/ those same OpenVPN clients.

    In my own case, I usually create a special cert named "site2site" for the site-to-site config, then generate a single cert named "client" for road-warrior purposes. Only the "site2site" cert is configured in the "Allow Only These Clients" section of the OpenVPN server.
     
  13. eibgrad

    eibgrad Network Guru Member

    Not only can they, they *must* be!

    When the OpenVPN client connects to the OpenVPN server in a bridged configuration, that OpenVPN client gets assigned an IP from the remote network. That client has the exact same access to the remote network as if it was physically patched to the switch on the remote network's router. And bi-directional access is implicit (no routing necessary) since the OpenVPN client and the remote clients all share the same *logical* ethernet segment, and by extension, the same local IP network.

    In short, you can think of the VPN as nothing more than a virtual ethernet cable between the client and remote router.

    IOW, the whole point of a bridged VPN is to do away w/ all the routing issues. There's isn't even a firewall between the OpenVPN client and the remote clients. That OpenVPN client might as well be physically located on the remote network in terms of its access and behavior. That's what makes it so clean and simple. The complexity comes into the picture when you use a routed VPN. Now each side has its own ethernet segment, its own IP network, network discovery doesn't work across the ethernet segments, firewalls (the router and the local ones) get in the way, etc. But sometimes a routed VPN is your only option (e.g., connecting to a friend's network).

    When using a bridged VPN, the options will be slightly different, but the "Manage Client-Specific Options" would seem to be irrelevant.

    Can't say for sure, never measured it. Sounds like something you could dig out from Google w/ some persistence.

    The router configures everything. In fact, because it's bridged, there's almost no firewall rules other than one to open the OpenVPN server port. It's a routed VPN that ends up requiring more firewall rules since now you have to manage routing between the VPN's network interface and the other network interfaces on that router. In the case of a bridged VPN, the VPN's network interface is simply bridged to the default network (br0) (unless you opt for a different one) and you're done.

    Not sure I understand what "they" are saying. To be honest, I'm not much of a Windows user these days. FWIW, I was recently told that network discovery *may* work across a routed VPN *if* each side was using the same Windows workgroup, and by inference, I assume they would need to be registered w/ the same WINS server. But that's beyond my own experience and knowledge. You'd have to experiment a bit and find out. Perhaps that's what they were alluding to. Give me the link if you have it.
     
  14. Dutch87

    Dutch87 Addicted to LI Member

    Dear Eibgrad,

    Again, thank you so much for answering all my questions! For me it cleared up a lot!

    I got the importance of the commonname in the certificates and will generate some more.

    So, I'll absolutely need a bridged VPN where Router-A's DHCP server hands out the IP's. When I take my laptop to LAN B i'll only experience the slower speed of the 4G module, but all the rest should be absolutely the same LAN wise :D. I cant wait to test the Steam link over VPN (a) (I guess it's their whole point you're not supposed to use it over WAN).

    I'm going to test and google some more around.

    So far my setup will be:
    Router A (192.168.1.x) will have two VPN servers, one for a TUN site-2-site for Router B and one TUN for when I'm on the road with my laptop or cell phone, where the DHCP of Router A handles all the IP's so I keep my fixed IP rules for portforwarding. Then I have to make a config where also all the DNS requests are handeled by the internal DNS server of Rourter A and no traffic will bypass the VPN and no DNS request can bypass it's DNS on any VPN client.

    I'll post my findings later and if I can't work something out I'll also post it here and hope for your feedback.
    Then again there are little posts on this focussed on Tomato routers, so I hope this thread will be a help to other people with the same questions about the NAT on TAP and etc.
     
  15. Dutch87

    Dutch87 Addicted to LI Member

    With the TAP config home streaming and discovery works awsome! (Steam only need 734Kbps)
    But I still can't figure out the DHCP machanism.
    I first had to change the IP of router B to 192.168.1.2 since Router A is 192.168.1.1

    Here https://www.serverwatch.com/tutoria...Up-a-VPN-Server-on-a-Tomato-Router-Part-2.htm they discribe setting the client specific options, but i believe they are obsolete, and also when i disable compression all fails. When I set DHCP on the VPN server setting and disable DCHP on Router-B no IP is supplied.

    Is it possible that the IP given to a certain MAC adress by the DHCP server will be the same on LAN-A as on LAN-B? Will each router give IP's themselves? Can I add a static IP list that is the same on Router-A as on Router-B since a machine can only be connected to one LAN at the same time?

    So my questions are basically about the DHCP and/over VPN with static IP per MAC adress and I dont need any client specific options?

    Stuff I will test later is:
    • Did I get a persistent tunnel / no traffic leak
    • Will addblocking work for the VPN connection
    • How does QoS work with VPN (only on server, or also client etc)
    • Best compression settings (CPU usage on ARM vs. Data usage)
    If you happen to have any comments on then they are also very welcome.

    Thanks in advance and kind regards!
     
  16. eibgrad

    eibgrad Network Guru Member

    In all the years of using a bridged OpenVPN, I've never seen the use of the dhcp option work. I've *always* had to set the dhcp range manually. Just seems to be a bug. And if this is the only OpenVPN client that's connecting to that OpenVPN server, you can limit the client address pool to a single IP.

    Sometimes this isn't obvious to ppl, but realize that the client address pool specified on the OpenVPN server is **only** for OpenVPN clients. The devices behind the OpenVPN client that will be using the tunnel established by the VPN will get their assignments from the DHCP server on router A, just like every other device on router A. That's why you disable the DHCP server on router B and bridge the OpenVPN client to the default network (br0).

    IOW, dhcp wrt the LAN clients is only being managed from router A's side. So you can configure the dhcp server on router A without being concerned about which side of the tunnel the request is coming from. If you want to establish static leases based on MAC address, do so, regardless of which side the client is coming from.

    I'm not sure why there is a section "Manage Client Specific Options" in the case of a bridged VPN. Most of the options contained therein are related to routing, but a bridged VPN eliminates the need or relevance of routing. I'm sure you could find a reason and purpose for it, but at the moment, it's not obvious. And shouldn't be a concern.

    One of the things you have to do when dealing w/ a bridged VPN, esp. having come from a routed VPN, is change your thinking. The only thing router B is doing is establishing a tunnel to the remote network on router A. And that tunnel is then bridged to the local network interfaces (br0) on each side of the tunnel. That tunnel is now nothing more than a virtual ethernet cable between the two routers. You can think of router B as being nothing more than a switch that's magically patched to router A's network w/ that virtual ethernet cable. It's incredibly simple. And that's what throws ppl. They keep overthinking it, making it more complex than it really is, because they're so used to the complexity of a routed VPN.
     
  17. Dutch87

    Dutch87 Addicted to LI Member

    Dear Eibgrad,

    Thank you for your answers, althoug about the DHCP over VPN they seem confusing to me

    I tried manny different options, only my machines connected to Router-B dont get an IP when I disable the DHCP on Router-B. So for short. Does DHCP over OpenVPN work, or doesnt it?

    Furthermore, I setup 2 VPN servers:
    -Site2Site: no compression and perfect bridge except for the DHCP, not sure what is normal
    -Site2Road: compression and for android phones / windows laptops. I hope the DHCP of Router-A will hand out the same IP's over VPN as it would on its physical side of the LAN.

    So im stuck at:
    -Making the DHCP over VPN work on Site2Site
    -Making TLS-handshake work with my .ovpn file using site2road
    -And hoping handing out IP's goed same on the site2road vpn as over the local wifi using the static DHCP of Router A

    Here are my config and screenshots:
    Tron-A DHCP.jpg Tron-A VPN Server A1.png Tron-A VPN Server A2.jpg Tron-A VPN Server B2.jpg Tron-A VPN Server B1.jpg

    And .ovpn config
    pull
    client
    remote xxxx.xx 1197
    remote-cert-tls server
    dev tun0
    proto udp
    nobind
    persist-key
    persist-tun
    float

    #redirect-gateway 192.168.1.1
    #redirect-gateway def1
    #dhcp-option DNS 192.168.1.1

    ca ca.crt
    cert client.crt
    key client.key
    tls-auth ta.key 1

    Thanks in advance!
     
  18. Dutch87

    Dutch87 Addicted to LI Member

  19. eibgrad

    eibgrad Network Guru Member

    On the OpenVPN server, do *NOT* check "DHCP" for the "client address pool" setting! As I said before, in all the years I've been using that option, I've never seen it work. In theory (as I understand it anyway) it's supposed to use the dhcp server on router A. But again, I've never seen it work. It's been so long since I've even bothered, I don't remember the symptoms, but either the OpenVPN client doesn't get an IP assignment, or it does, but no gateway is included. So instead, uncheck DHCP and configure it manually. Set aside some IPs on router A's local network for the OpenVPN clients (e.g., 192.168.1.200 thru 192.168.1.203) that are outside the scope of its DHCP server.

    Again, this pool (192.168.1.200 thru 192.168.1.203 in my example) is *only* for the OpenVPN clients. Once the OpenVPN client is connected and the tunnel established, the LAN clients behind the OpenVPN client will use the tunnel to access router A's DHCP server.

    So don't get confused between the two DHCP issues.
     
    Last edited: Apr 30, 2018
  20. Dutch87

    Dutch87 Addicted to LI Member

    Sorry and thanks again!

    So all my IP's are x.100 and higher, so I set VPN server 1 (site2site) to 10 and 2 (site2road) to 20-29. Giving out only 1 IP was the problem somehow at first but, then rebooted and now DHCP works! So, as it seems now, the Site-2-Site part works!!!

    Also without compression the speed got better, its overall 4,85MB/s when QoS disabled. Since my upload is only 4MB/s this setup is nu perfect in every way for Site2Site :D.

    Could you still help me with the config for the site-2-road ovpn file?
    Here I hope the DHCP of router-A will again hand out the predifined IP's.
     
    Last edited: Apr 30, 2018
  21. eibgrad

    eibgrad Network Guru Member

    It only makes sense to use both OpenVPN servers if there is a *significant* difference in the configuration required by OpenVPN clients (e.g., bridged (tap) vs. routed (tun)). For minor differences, that can sometimes be addressed by specifying per-user configuration options. For example, if for some reason it mattered which IP was assigned to which OpenVPN client, you could specify an ifconfig option in the CCD file for that client (based on its common name). Not sure about something like compression.

    In this case, if you intend to use the second VPN w/ Android (or other mobile devices), beware that mobile devices typically don't support bridged VPNs! It has to be routed (tun).

    P.S. If you specify Adaptive for LZO compression, the VPN will periodically assess whether using compression helps or hurts, and adjust accordingly. How well that process works, I don't know. But that's the theory anyway.
     
    Last edited: Apr 30, 2018
  22. Dutch87

    Dutch87 Addicted to LI Member

    Well, the major difference is the common name of the vertificate used by the site2site vs site2road.

    If you are sure that TAP would be a problem with my OVPN GUI with windows 10 and Android OpenVPN software ill set it up with the TUN setup and the NAT/firewall rules you explained earlier (because of the windows firewall). I have seen some outdated tutorials using TAP i.c.w. android of which i copied the ovpn file command from and tried to google what they all mean.

    At the moment I get stuck at the TLS handshake part and I dont know how to specify the DH path in the client OVPN file, not sure if it should even be there. Can you see what is wrong with this config? I'm goint to try TAP still and see how far I can get with it (a)

    Also true, but after lots of googeling and reading and also after doing my own test with filetransfers, 0,8MB/s higher filetransferrates are achiefed this way wich is most important for me when the NAS'ses have to sychronise. Also people warn that sending uncompressable data over a LZO line will make data consumtion higher +1. I still have to see how much will be gained with compression on with the same file transfer. To be continued
     
  23. eibgrad

    eibgrad Network Guru Member

    That's not the kind of difference I'm talking about. That's just a difference in identification. Once you've uniquely identified a client, you might then want to configure those clients a bit differently.

    When you were configuring the OpenVPN server in routed (tun) mode, the purpose of using different common names was so you could, in the case of the site2site OpenVPN client, add the local network behind that OpenVPN client in the "Manage Client Specific Options" section, along w/ that common-name. If you had added another OpenVPN client for road-warrior purposes, that OpenVPN client would NOT have had an entry in the "Manage Client Specific Options" section.

    IOW, the reason for the two common-names was to distinguish one OpenVPN client from the other in order to know which OpenVPN client needs the routing information in "Manage Client Specific Options".

    But now you have a bridged VPN. And now routing is irrelevant. Any bridged OpenVPN client to the same OpenVPN server is pretty on-par with any other. There are no distinctions to be made, except perhaps (as I indicated in the prior post) wanting to assign specific IPs to specific OpenVPN clients. Or perhaps other minor differences (e.g., compression settings). But beyond that, there aren't many differences. And so having everyone use the same common-name at that point is probably sufficient.

    At least in my experience (things could always change in this regard), mobile devices don't support bridged VPNs. You should get an error once the device attempts to use the config file and see the connection type is TUN. Why they don't support it, I have no clue. But that's just another reason choosing bridged vs. routed for OpenVPN is not always an easy decision. At least tomato offers two configurations, whereas something like dd-wrt does not (although you could script the second instances if you needed to).

    The DH params only belong on the OpenVPN server config, NOT the OpenVPN client config.

    Can't really help you much w/ this issue. When it comes to tweaking the connection w/ things like compression, you'll just have to play with it and see what you get.
     
  24. eibgrad

    eibgrad Network Guru Member

    P.S. Although a bit more complex to setup and manage, it might be worth considering taking another router w/ you on the road that is configured as a bridged OpenVPN client, then connecting to *it* rather than directly to the local wifi. IOW, rather than configuring a routed OpenVPN on the mobile device, place that router between your mobile device and the local wifi so you can still used a bridged VPN. I've done this myself from time to time using a smallish travel router. As I said, it adds some complexity and hauling around some extra hardware, but it might be worth it in some cases.
     
  25. Dutch87

    Dutch87 Addicted to LI Member

    Dear Ebgrad, thank you for all your help and understanding.

    So I have now a perfect working true site2site VPN with 4,8MB/s troughput. If I want a TUN vpn for me it seems irrelevant to use the router to this purpose since any client connected could serve as a TUN VPN server. Since I cannot get the OVPN file to work on my laptop for the second VPN server using a different certificate for the same TAP true site2site VPN I'm giving up.

    I assume this Router A should also be able to accept a 3rd router Router C when its exactly configured as is Router B, so future expansion also seems possible to me.

    For on the road I ofcource dont have a 220V or 12V power outlet with me, just my laptop and unlimited 3G internet.

    I configured my NAS in TUN mode wich has a open VPN trouhput of 48,5MB/s and will so far server for the TUN VPN services.

    So I only have to make a 4G dongle work on router B. I have one that is a few years old from Huawei that works fine on an older asus router. I hope it will work as well on this one.

    Again thanks a lot for helping me with so much!
     
  26. Dutch87

    Dutch87 Addicted to LI Member

    Sorry, another problem:
    I'm reading the logs now on the router B and its spamming this line every 2 seconds:
    What could it mean and how to fix it?

    user.notice root: vpnrouting: searching gateway for tun11

    To me it all feels working perfect, but having it make a new syslog file of 1 mb every day is also to much...
     
  27. eibgrad

    eibgrad Network Guru Member

    AFAIK, that message is related to using the Routing Policy tab. Are you using that feature? If not, make sure it's disabled.
     
  28. Dutch87

    Dutch87 Addicted to LI Member

    EDIT: After setting it back to TUN the setting appeard and i disabled it. Now testing it...

    UPDATE: It worked! Thanks!!!

    The Redirect Internet traffic Gateway I keep enabled I believe. Its set to 192.168.1.1
     
    Last edited: May 1, 2018
  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