[SOLVED]Traffic from internal LAN cannot route via OpenVPN client

[EddieA]

I've set up the OpenVPN Client on my Zentyal system and by creating my own config file have been able to successfully connect to the server.

It took me a while to realise that I needed to add my own route to the Kernel IP Routing Table to allow the traffic to flow via the tun0 interface instead of eth0.  The route I added only sends a certain IP range through the tunnel.  The rest is routed out to the internet normally.  The last line being the one I needed to add:

Code: [Select]

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.10.10.0      10.10.10.177    255.255.255.0   UG    0      0        0 tun0
10.10.10.177    *               255.255.255.255 UH    0      0        0 tun0
142.129.208.0   *               255.255.240.0   U     0      0        0 eth0
192.168.0.0     *               255.255.255.0   U     0      0        0 eth1
192.168.160.0   *               255.255.255.0   U     0      0        0 tap1
212.58.240.0    *               255.255.240.0   U     0      0        0 tun0
Now, from the Zentyal server itself, this is working perfectly.  If I traceroute to the 212.58.240.0 range, I see it going via the 10.10.10.0 hop.  If I traceroute any other address, then it goes straight to my ISP.

Now, the only issue is, I can only do this from the Zentyal server itself.  If I try routing anything to the 212.58.240.0 range from a machine in the internal LAN, then it just times out connecting.  I've tried browsing, traceroute, ping, telnet, etc. and it's always the same.  Zentyal server = success.  Machine on LAN = fail.

I initially thought it might be the firewall, but if it is nothing shows in the logs.  Also, the firewall is port based, not IP, so I don't really see it being that.

Any ideas of why my internal traffic is failing to be routed at all.

Also, I'm a little confused how the routing works anyway in an standard Zentyal system, as there is no "default" entry in the routing table to send the packets to my ISP gateway.

BTW  This is a fully up to date 3.0 system.

Cheers.

[christian]

You should not have to manually manage routes: this is the purpose of "advertised network".
Except if you have another route defined at LAN level (I mean for machines on LAN), these machines should have Zentyal as their default gateway. No need to defined any specific route on these machines. Packets will reach Zentyal from where route to your specific network is known.
Try to use "advertised networks" feature and try again.

As like with modern Linux, routing is managed using iproute2, reason why route command shows only partial view.

[EddieA]

Chrisian,  Thank you for replying, especially the hint about iproute2.  Now I understand how the default routing takes place:

Code: [Select]

ip route list table default
default via 142.129.208.1 dev eth0
However, that really doesn't help with the issue at hand.

Just for clarification, this is not a Zentyal <-> Zentyal tunnel.  It is Zentyal -> foreign VPN server.  This server does not advertise any networks, as by default it attempts to hijack the default route for all the traffic.  This fails within Zentyal because there is no default route in the kernel table:

Code: [Select]

Mon Jul 22 15:09:39 2013 SENT CONTROL [scothosts.com]: 'PUSH_REQUEST' (status=1)
Mon Jul 22 15:09:39 2013 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option NTP 10.10.10.1,dhcp-option DNS 10.10.10.1,ping-timer-rem,route 10.10.10.0 255.255.255.0,topology net30,ping 10,ping-restart 60,ifconfig 10.10.10.178 10.10.10.177'
Mon Jul 22 15:09:39 2013 OPTIONS IMPORT: timers and/or timeouts modified
Mon Jul 22 15:09:39 2013 OPTIONS IMPORT: --ifconfig/up options modified
Mon Jul 22 15:09:39 2013 OPTIONS IMPORT: route options modified
Mon Jul 22 15:09:39 2013 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Jul 22 15:09:39 2013 ROUTE: default_gateway=UNDEF
Mon Jul 22 15:09:39 2013 TUN/TAP device tun0 opened
Mon Jul 22 15:09:39 2013 TUN/TAP TX queue length set to 100
Mon Jul 22 15:09:39 2013 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Jul 22 15:09:39 2013 /sbin/ifconfig tun0 10.10.10.178 pointopoint 10.10.10.177 mtu 1500
Mon Jul 22 15:09:41 2013 NOTE: unable to redirect default gateway -- Cannot read current default gateway from system
Mon Jul 22 15:09:41 2013 /sbin/route add -net 10.10.10.0 netmask 255.255.255.0 gw 10.10.10.177
Mon Jul 22 15:09:41 2013 Initialization Sequence Completed
The reason for the manual adding of the route is explained by Javier in this post.

So, my reading of the route and iproute2 information still leads me to believe that I have the routing correctly set.  This is confirmed by the fact that everything is routed, exactly as expected, for anything that takes place on the local Zentyal server.

So, I am back to the issue, which I believe is this.  Whatever mechanism is used to enable the transfer of outgoing packets from the LAN interface, eth1, to the WAN interface, eth0, is only allowing just that, eth1 -> eth0 and when the routing information kicks in, and attempts eth1 -> tun0, this is blocked.

Where would be the next place for me to investigate this aspect.

Cheers.

[EddieA]

OK, eventually got to the root of this.

It needed an additional entry in the nat postrouting section:

Code: [Select]

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEI guess this would all be done internally, if Zentyal would allow tun/tap interfaces to be defined as gateways.

Cheers.

[sergani]

Hello Eddie,

Thanks for the nat rule you added below, I was missing that.

I noticed however that the rules are regenerated whenever changes are saved, and my nat rule would disappear.

Do you know the set of script that Zentyal runs to save changes? I might be able to add the nat rule in them.

This is one thought, otherwise help is appreciated. I need the nat rule to stay there across configuration "saves", and reboots of course.

Thanks
//M