Zentyal Forum, Linux Small Business Server
Zentyal Server => Installation and Upgrades => Topic started by: jbo5112 on April 13, 2013, 11:55:52 pm
-
I'm trying to run a Zentyal-to-Zentyal tunnel that will connect two different LAN's, where both Zentyal servers (v3.0 & v2.2) are acting as routers. The tunnel is up and running, and the Zentyal servers can talk to each other just fine. However, they do not route the LAN traffic across the tunnel. The Zentyal server running v2.2 is at our data center, and hosting the VPN. The v3.0 server is at a software development office, and runs a client. I can only get it half-way working.
Server 1 (data center - Zentyal 2.2)
LAN IP: 192.168.1.1
VPN IP: 192.168.250.1
Advertised network: 192.168.1.0/24
Server 2 (dev office - Zentyal 3.0)
LAN IP: 192.168.2.1
VPN IP: 192.168.250.2
I've added the code to the firewall.postservice hook on each of the services.
iptables -t nat -A POSTROUTING -o <vpn-interface> -j MASQUERADE
The 192.168.1.x network can ping anything on the 192.168.2.x network, including Server 2's ip address for another VPN (192.168.122.1). Server 2 can ping anything on the 192.168.1.x network. Anything on the 192.168.2.x network can ping 192.168.250.1, but not the 192.168.1.x network. If I disable the rule on Server 1 and reboot the server, then computers on 192.168.2.x can ping servers on the 192.168.1.x network, but it obviously disables the 192.168.1.x network pinging servers on the 192.168.2.x network, except I think Server 1 itself can ping 192.168.2.x. Just deleting the rule or restarting the firewall doesn't seem to work. I think restarting the VPN on Server 1 might fix it, once the rule is removed, but I don't remember. I'd like to get this sorted out so I can sync a demo and development database.
*updated Server information*
-
Perhaps a stupid question but I don't understand why you want VPN network to be able to ping LANs.
What does it bring in term of feature?
Another stupid question: have you advertised what you intend to reach ?
-
As a side note, it might be interesting some day to see how the Zentyal community understands and uses (or at least tries to use) Zentyal's VPN services--as a server-client network or as a peer-to-peer network, and why.
-
I suppose both are used.
I've set-up some month ago full test-bed made of 3 Zentyal servers (2.x) for IRC use (and also forum member) wiling to connect via internet 2 remote locations to central location in order to get rid of satellite based leased lines.
Zentyal to Zentyal VPN was the obvious answer to his problem.
Building test-bed locally and having it working was quite easy but then explaining how to reproduce this in real life with remote deployment to admin not getting all concepts clear in mind appeared to be much more challenging. :-X
-
I suppose both are used.
I suppose the same thing. But after reading posts over the years I find myself not always understanding what people are trying to accomplish across a VPN. Some of the things I don't understand are surely out of my ignorance of such things, and some I was not able to get to work (again, maybe because of my ignorance) as a learning experience.
For my part I always thought of VPN along the lines of a client-server model--accessing centrally located services remotely and administrating remote devices centrally. After reading this topic and not understanding the goal, I thought once again about the fact that people must view VPN itself differently.
-
You perhaps react also to my question to jbo5112: "What does it bring in term of feature?"
I often refrain myself to ask such question, not only with VPN but also other services while reading some posts here as I've the feeling that some users are trying to implement services for which they do not really understand what it brings or what it is supposed to bring.
Like you, I see VPN as a kind of, "client-server" aiming to extend your LAN over potentially insecure line by building secure tunnel.
So this is "many-to-one" service.
Zentyal to Zentyal tunnel makes no exception as one Zentyal is acting as server while the other is acting as client. This is perhaps not always understood, especially because there is no mechanism populating routing table over you extended LAN. As a result, VPN server side is known from VPN client side but the opposite is not true unless you advertise this client network.
To be noticed that this only works if Zentyal server, VPN server side, is either de default route for devices on the LAN or if specific route "through Zentyal server" is published.
With above explanation, I don't see where there is e need to check connectivity from VPN segment itself to either server side LAN or client side LAN, therefore my question to jbo5112
-
I have servers at our data center that I need to access from the development office. I also have servers at the development office that need to be accessible from the data center, though not quite as urgent. It would also be nice if, at some later point (should we grow), a second development office could be added to the mix, where everyone can see each other. Enabling this would allow any server or workstation to run a service that is listening for a remote connection from any location for things like file transfers, syncing mostly read-only databases, git pushes/pulls, etc.. It may not be the most professional, enterprise setup, but with a small, trusted development group and slow upload speeds at remote offices, it seems an easy and reliable way to keep everything up to date, including a live demo of our development efforts.
The data center, acting as host, has its network listed as advertised, client-to-client connections are on, Zentyal-toZentyal tunnels are on, and I've tried both settings for NAT. The client does not have any configuration that I can find for advertising a network. Once the tunnel is running, the two Zentyal servers could connect to anything on the remote LAN, without any hooks, but as for the other servers and workstations, they could only talk to their own LAN and addresses on the VPN (the remote and local Zentyal servers). I can only see a limited use for this configuration, and I cannot imagine that this was the intended purpose of a Zentyal-to-Zentyal VPN.
I was expecting to run a standard VPN server on both Zentyal machines and making each of them a client for the other VPN. I think I even untarred a standard Linux client bundle on the office router, without it being noticed by Zentyal's OpenVPN. Seeing an option for a Zentyal-to-Zentyal tunnel, my expectation is it would make the two networks operate like connected peers (i.e. automatically route/NAT traffic between them).
-
Seeing an option for a Zentyal-to-Zentyal tunnel, my expectation is it would make the two networks operate like connected peers (i.e. automatically route/NAT traffic between them).
Exactly the kind of observation I think it would be helpful to collect in a more organized way if only because it would help us as a community to understand user expectations better. We're not all on the same page when it comes to VPN for a variety of reasons (including choice of the underlying technology). Even small businesses aren't all cast from the same mold, so needs and expectations will differ.
Better yet, hopefully a more robust community understanding of both the technologies involved and the expectations of administrators will yield better community support and better feature suggestions. Thank you for taking the time to fill insome of the details. :)
-
I was expecting to run a standard VPN server on both Zentyal machines and making each of them a client for the other VPN. .../... Seeing an option for a Zentyal-to-Zentyal tunnel, my expectation is it would make the two networks operate like connected peers (i.e. automatically route/NAT traffic between them).
Sure but if you read carefully this documentation (http://doc.zentyal.org/en/vpn.html#configuration-of-a-vpn-server-for-interconnecting-networks), you will notice:
When the connection is complete, the host with the server role has access to all routes of the client hosts through the VPN. However, the hosts with client roles will only have access to those routes the server has explicitly advertised.
which means that it doesn't provide exact peer-to-peer (in term of routing).
Notice I'm not saying you can't achieve it but you do need to advertise what you want to reach.
While writing this, I'm wondering if it makes sense to configure on each Zentyal (meaning on each side) one VPN server and one VPN client... ::)
I'll try to play with this in order to improve my understanding.
-
Glad I could help, Sam Graf.
I'm looking at two copies of the documentation, both with and without the section you quoted Christian. The first few times I opened the page, it cut off before the section on "Configuration of a VPN server for interconnecting networks", but I'm looking at it now. I'm pretty sure the two hosts are behaving just like you said in the quote. I'm able to give each Zentyal Server secure remote access to a remote LAN. However, "The goal is to connect multiple offices, their Zentyal servers and their internal networks so that one, single network infrastructure can be created in a secure way and through Internet." The documentation in version 2.2 stated: "The goal is to connect the client 1 on the LAN 1 with client 2 on the LAN 2 as if they were in the same local network." Their instructions are rather similar
Using the networking image from the 2.2 documentation to help explain my situation:
(http://doc.zentyal.org/2.2/en/_images/two-offices.png)
Client 1 can connect to any service on LAN 1, ZENTYAL OpenVPN Server, or ZENTYAL OpenVPN Client (via the Zentyal-to-Zentyal VPN IP address), but client 1 cannot connect to client 2.
Client 2 can connect to any service on LAN 2, ZENTYAL OpenVPN Client, or ZENTYAL OpenVPN Server (via the Zentyal-to-Zentyal VPN IP address), but client 2 cannot connect to client 1.
ZENTYAL OpenVPN Server and Client can both access anything pictured.
I have the proper LAN advertised by the OpenVPN server, and I updated the configuration in my first post to reflect that. I can also apply extra hooks into Zentyal that fixes the problem for either client 1 or client 2, but not for both at the same time (probably my lack of knowledge). However, it sounds like this should be done automatically. Left alone, the VPN doesn't connect client 1 to client 2.
Am I misunderstanding the Zentyal-to-Zentyal tunnel? Are only the Zentyal machines supposed to see both clients, and the two client computers (client 1 & client 2) not talk to each other? I had to manually reconfigure the Zentyal 2.2 machine to push DHCP options for DNS and domain (via a customized copy of openvpn.conf.mas in /etc/zentyal/stubs/openvpn/openvpn.conf.mas), which I seem to only be able to apply to all VPN's, but that shouldn't affect anything, especially since I'm using IP addresses for testing. Could my problem be a bug in Zentyal 2.2, where I should upgrade ASAP and ignore the problem until then?
-
Zentyal to Zentyal documentation in V 3.0 section was not previously published. It has been fixed yesterday, reason why, except if you refreshed cache, it didn't appeared first.
Anyway, to me documentation is clear enough: such design aims at permitting devices on LAN 2 to access devices on LAN 1, no need for any hook and if it doesn't work (of course with the right settings) then there is a bug to be reported.
If you also want devices on LAN 1 to be able to reach devices on LAN 2, then special setting is needed (advertising)
In term of feature, again, documentation is clear, at least from my standpoint ::)
Because of this, I suggest we focus on the technical aspect and instigation steps to identify what works for you and what doesn't (without introducing any hook and workaround) so that you can:
- report a bug if there is one
- find solution fitting your needs
I would like, before we drill down, clarify 2 more aspects that may lead to some confusion:
- for what I tested some moth ago, Zentyal server-to-server VPN doesn't handle any DNS and DHCP service. Thus I suggest we, at least temporarily, keep it out of the scope and then come back on it once VPN permits device to device connectivity.
I'm going to build here you example with 2.2 and 3.0 Zentyal servers and I'll come back to you once done.
-
I wanted to make sure that I'm clear on what it should be doing and what it is actually doing, and I agree with your suggestions on how to proceed.
You are correct on the DNS and DHCP services. I think the push statements are merely suggestions, but either way, the Linux client program defaults to ignoring any DNS and DHCP options that are pushed. The Windows client program defaults to accepting the pushed statements. I just brought it up because I have had problems in other situations that were caused small customizations that I didn't think mattered.
Thank you for looking in to this. I'm sorry if I'm not more help in the problem, but my primary job is with software development.
-
I just achieved few minutes ago testbed deployment and tests based on here attached picture.
Without any specific set-up, I can, from B, access web servers in location A.
I also installed nginx on A (which is a laptop) and can connect from workstation in B
So I'm wondering what is not working on your side ???
Notice I'm not currently trying to access using names as DNS is not set yet.
-
I'll try configuring everything with fresh installs, using a virtualized environment. If my virtual setup works, then I know I've probably done something wrong with the systems that is breaking things. With the other projects I have going, it might be a day or two before I get everything finished.
Once I get the VPN up, I'll probably just manually clone the important parts of the two DNS zones.
-
As I previously wrote, what really matters with such investigation is to really distinguish between the various components and layers.
Test I made is showing the evidence that Zentyal server-to-server works as expected and permits to enable, through VPN tunnel, site to site communication, both ways (even mixing 2.2 & 3.0 Zentyal servers)
Then, from an end-user standpoint, this is not the end of the story. If you don't look further, you may not be able to reach service on the other side.
- everything needs to be perfectly aligned in term of default route
- you may obviously want to access service name, not IP, thus DNS content does matter and might be tricky if both sides share same IP domain name
That's the reason why I suggested that you split investigation into slices, not trying to solve end-user issue introducing workaround like iptables rules but identifying where problem lies.
Let us know the outcome of your test but be caution if you connect everything on same LAN because of routes ;)
-
I got my virtual environment set up and configured. Everything is working fine there, so I guess I'll have to start digging around at settings. The problem is I'm not sure of much to look at, besides replicating more of my settings in the virtual environment. The routes and NAT iptable look okay, but there is a lot in the iptables.
I did find and file a minor bug (here (http://trac.zentyal.org/ticket/6545)) on the UI for adding a new VPN Client, but the worst the bug will do is confuse someone.
-
The routes and NAT iptable look okay, but there is a lot in the iptables.
Could you explain what you mean ???
I think I understand all words but not the meaning of this sentence :-[
-
When I look at the routes on both servers, everything looks okay . When I look at the NAT iptable (`iptables -L -t nat`), everything looks okay on both servers. There are a lot of things listed in iptables, so I could easily miss something.
-
There is an error in the documentation:
When the connection is complete, the host with the server role has access to all routes of the client hosts through the VPN. However, the hosts with client roles will only have access to those routes the server has explicitly advertised.
The error is the client only advertises to server networks which are inside private IP address spaces: http://en.wikipedia.org/wiki/Private_network . Other networks are not advertised to the server.
-
Aside of the glitch of the documentation, the typical error here is that hosts on one LAN don't have a return route to the other LAN. The easier way to rule this is to have the Zentyal server as default gateway; if this is not possible you have to create explicit routes to the other LAN using the Zentyal as gateway,
-
There is an error in the documentation:
When the connection is complete, the host with the server role has access to all routes of the client hosts through the VPN. However, the hosts with client roles will only have access to those routes the server has explicitly advertised.
The error is the client only advertises to server networks which are inside private IP address spaces: http://en.wikipedia.org/wiki/Private_network . Other networks are not advertised to the server.
I can't see what's wrong with documentation.
advertising is available server side (not client side) and goal is to tell VPN client that routes advertised by VPN server must be reached connecting through VPN.
This permits, e.g. VPN client to connect to other LAN via server's LAN (e.g. another "VPN connected" client ;))
Am I wrong ?
-
There is an error in the documentation:
When the connection is complete, the host with the server role has access to all routes of the client hosts through the VPN. However, the hosts with client roles will only have access to those routes the server has explicitly advertised.
The error is the client only advertises to server networks which are inside private IP address spaces: http://en.wikipedia.org/wiki/Private_network . Other networks are not advertised to the server.
I can't see what's wrong with documentation.
advertising is available server side (not client side) and goal is to tell VPN client that routes advertised by VPN server must be reached connecting through VPN.
This permits, e.g. VPN client to connect to other LAN via server's LAN (e.g. another "VPN connected" client ;))
Am I wrong ?
I feel like you and Javier are talking about two different things. And I'm not sure I understand the scenario you're describing. If I have a Zentyal server (server A) running two VPN servers, one for each of two remote Zentyal client machines (servers B and C), I don't think server A links the LANs of servers B and C. Nor do I think a road warrior client of another VPN server on server A has access to the LANs of servers B and C.
Am I wrong?
-
What I describe could be indeed this or another, not necessarily via VPN, remote site connected to A.
If you don't advertise C, when B connects to A, there is, on B side, no route to C unless A advertises it.
This is my point.
-
Aside of the glitch of the documentation, the typical error here is that hosts on one LAN don't have a return route to the other LAN. The easier way to rule this is to have the Zentyal server as default gateway; if this is not possible you have to create explicit routes to the other LAN using the Zentyal as gateway,
If I make Server 1 the default gateway, I lose 30-40% of my download speed on Server 2. It's possible, but a bad idea. I don't see anything missing from my route that I need to create. I deleted the public IP's and default gateways from the list below for privacy.
Server 1 is hosting the VPN, and is only configured to be advertising 192.168.1.0/24. Somehow the VPN link is also advertising 10.202.0.0/20 and 192.168.160/24, since it only comes up when that VPN is connected. I assume tap0 on Server 1 and virbr0 on Server 2 have to do with my Zentyal subscriptions, since I didn't set up anything like that.
Server 1 (data center - Zentyal 2.2)
LAN IP: 192.168.1.1
VPN IP: 192.168.250.1
Advertised network: 192.168.1.0/24
tap0 Link encap:Ethernet HWaddr 6a:c2:fe:06:2c:81
inet addr:10.202.3.212 Bcast:10.202.15.255 Mask:255.255.240.0
inet6 addr: fe80::68c2:feff:fe06:2c81/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:720 (720.0 B)
tap1 Link encap:Ethernet HWaddr 4e:e1:e9:f5:e9:f2
inet addr:192.168.160.1 Bcast:192.168.160.255 Mask:255.255.255.0
inet6 addr: fe80::4ce1:e9ff:fef5:e9f2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:24219 errors:0 dropped:0 overruns:0 frame:0
TX packets:22100 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:3720565 (3.7 MB) TX bytes:4981028 (4.9 MB)
tap2 Link encap:Ethernet HWaddr 06:cf:a8:0a:18:f6
inet addr:192.168.250.1 Bcast:192.168.250.255 Mask:255.255.255.0
inet6 addr: fe80::4cf:a8ff:fe0a:18f6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:270 errors:0 dropped:0 overruns:0 frame:0
TX packets:489 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:31708 (31.7 KB) TX bytes:68374 (68.3 KB)
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 192.168.250.2 255.255.255.0 UG 2 0 0 tap2
192.168.160.0 * 255.255.255.0 U 0 0 0 tap1
192.168.250.0 * 255.255.255.0 U 0 0 0 tap2
192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
192.168.122.0 192.168.250.2 255.255.255.0 UG 2 0 0 tap2
10.202.0.0 * 255.255.240.0 U 0 0 0 tap0
10.200.0.0 10.202.0.1 255.255.0.0 UG 0 0 0 tap0
Server 2 (dev office - Zentyal 3.0)
LAN IP: 192.168.2.1
VPN IP: 192.168.250.2
tap0 Link encap:Ethernet HWaddr 66:58:03:4d:6e:56
inet addr:192.168.250.2 Bcast:192.168.250.255 Mask:255.255.255.0
inet6 addr: fe80::6458:3ff:fe4d:6e56/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:354 errors:0 dropped:0 overruns:0 frame:0
TX packets:186 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:50284 (50.2 KB) TX bytes:22944 (22.9 KB)
virbr0 Link encap:Ethernet HWaddr 36:26:0a:0e:79:af
inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.202.0.0 192.168.250.1 255.255.240.0 UG 2 0 0 tap0
192.168.2.0 * 255.255.255.0 U 0 0 0 eth4
192.168.122.0 * 255.255.255.0 U 0 0 0 virbr0
192.168.160.0 192.168.250.1 255.255.255.0 UG 2 0 0 tap0
192.168.1.0 192.168.250.1 255.255.255.0 UG 0 0 0 tap0
192.168.250.0 * 255.255.255.0 U 0 0 0 tap0
-
If I make Server 1 the default gateway, I lose 30-40% of my download speed on Server 2. It's possible, but a bad idea.
Indeed this is a bad idea and not what Javier suggests. Furthermore it will not work because if, on site 2 (where server 2 runs) default gateway is, in a static way, server 1, you would never be able to establish VPN tunnel ;)
What Javier said is that on each location, the easiest way is to have server running VPN service (either server or client) defined as "local" default gateway. Meaning server 2 is the default gateway on site "2" and server 1 is the default gateway on site "1".
This is an advice for easy implementation but by no mean mandatory.
So to summarise:
- what you want to achieve does work (I did it here and you have also reproduced it on your side)
- it hopefully works without manually tweaking any configuration file
What might be difficult is to be sure that your current production environment is back to "standard" configuration given that you have already applied tweaks. Assuming this is however OK, then looking at routes should tell us whether problem lies here or not.
-
I am a bit hurry now, so just a quick clarification about the errata.
When the client connects to the server, the server is given routes to reach the client's connected internal networks using the client as gateway. (it is not instantaneous because the client should give the server the notification through the VPN)
What is not explained in the documentation is that the routes for the internal networks which don't use private addresses are not given to the server.
This only in tunnel scenario. In roadwarrior no route is given to the server.
-
Clear :)
-
Christian,
I saw your note in IdeaTorrent. Thanks for responding.
What I am trying to get is slightly different. The current way of zentyal to zentyal tunnel is something like this:
Zentyal A acting as server: LAN 192.168.0.0/24, VPN 196.168.160.0/24;
Zentyal B acting as client: LAN 192.168.1.0/24.
When connected, A will have 195.168.160.1, B 195.168.160.2, and traffic between two sites are routed (at layer 3?).
What I am hoping to get is to bridge the two sites (at layer 2?) so that everything is on 192.168.0.0/24 (for instance server A is 192.168.0.1 with some connected workstations occupying 192.168.0.10-20, and VPN clients in 192.168.0.200-220; whereas server B is 192.168.0.101 (and a possibly another ip assigned by the VPN), with some other clients occupying 192.168.0.110-120.)
-
OK, I understand that this is indeed different but don"t understand how this could happen neither what would be the purpose (except perhaps allowing communication for non-router protocols ?)
What I mean to say is that is, before tunnel is established, you have:
site A: 192.168.1.0/24
site B: 192.168.2.0/24
how can you imagine that IP addresses will change so that all devices are now on 192.168.1.0/24
What's about potential conflicts, in your example with devices on site B inheriting from 192.168.0.120 IP once tunnel is established with existing device on site A with same address ?
You may "link" 2 LAN over switch (this is level 2) but level 3 is routing.
So I'm very confused with your "idea". Not that this is meaningless but I just don't understand neither goal nor potential implementation aside building "switch".
Please feel free to comment and elaborate :)
-
Just to clarify. Both sites begin with the same 192.168.0.0/24 LAN, the assignment of IPs are planned ahead so that there is no conflict. Indeed the whole function of openvpn is to create a switch in this case.
-
OK clearer.
Would you mind pointing me to the OpenVPN documentation explaining how this works from technical standpoint ?
-
Sure, here are several tutorials on this topic:
http://www.aminus.org/blogs/index.php/2005/04/16/site_to_site_bridged_ethernet_using_open_2?blog=2
http://www.aminus.org/blogs/index.php/2005/04/16/site_to_site_ethernet_bridge_over_openvp_2?blog=2
https://www.linux.com/learn/tutorials/305765-how-to-bridge-networks-with-openvpn
http://www.linux.com/learn/tutorials/457103-install-and-configure-openvpn-server-on-linux
Note that I am not a pro in IT. So don't blame me if these don't work. ;)
-
Three more:
https://wiki.archlinux.org/index.php/OpenVPN_Bridge
https://help.ubuntu.com/11.10/serverguide/openvpn.html#openvpn-advanced-config (Scroll down a bit)
http://www.voip-solutions.org/voip-and-vpn.html
-
This one is from the official openvpn documentation:
http://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html
-
Thanks a lot.
All these cookbooks are pretty clear, some even describe potential side effects.
As none is describing real life implementation, if you succeed enabling such design (which should not be that difficult BTW), please let us know your feedback regarding regarding improvements (if any) and also how you finally deal with DHCP in case you have DHCP on each site.
-
Yeah, it is not difficult to implement as far as I can tell, if only I know enough about using command lines. :-[
In terms of DHCP, I guess as long as the option of blocking DHCP across tunnel is ticked in openvpn, there shouldn't be much problem. In addtion, if the tunnel is always on, one could potentially leave just one DHCP server active and allow DHCP across tunnel.