Zentyal-to-Zentyal tunnel connecting 2 LAN's

[jbo5112]

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) on the UI for adding a new VPN Client, but the worst the bug will do is confuse someone.

[christian]

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 

[jbo5112]

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.

[Javier Amor Garcia]

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.

[Javier Amor Garcia]

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,

[christian]

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 ?

[Sam Graf]

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?

[christian]

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.

[jbo5112]

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

Code: [Select]

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

Code: [Select]

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

[christian]

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.

[Javier Amor Garcia]

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.

[christian]

Clear 

[umggc]

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.)

[christian]

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 

[umggc]

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.