theVOID

Hi all!

We have a setup of three computers;
Machine A (eth0) -> Machine B (eth0, hso0, tun0) -> Machine C (eth0, tun0)

hso0 is the packet interface of a 3G modem, it behaves like a normal network interface.

Machine B and C are connected in a VPN using openVPN (TCP). Machine A is a client that receives Network-configuration using DHCP from Machine B automatically.

Machine A eth0 : DHCP
Machine B eth0 : 192.168.2.1
Machine B hso0 : Static IP addr, Internet use
Machine B tun0 : 10.11.0.10 (openVPN client)
Machine C eth0 : Static IP addr, Internet use
Machine C tun0 : 10.11.0.1 (openVPN server)

OpenVPN (server) is configured to allow Internet-traffic to its clients. Code in server.conf:
# Make sure clients traverse tun0 when accessing Internet
push "redirect-gateway def1"
# Push a DNS server (handled by openVPN)
push "dhcp-option DNS 10.11.0.1"

We’re having issues to make Machine C release Internet traffic from Machine A. Note that we have setup masquerading on Machine B using iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE.
Currently Iptables on Machine B and Machine C have a policy of ACCEPT.

We have managed to make traffic from Machine A reach Machine C, but only with the internal IP of 192.168.2.48 (DHCP).
OpenVPN drops those packets (as it should!) because they come from 192.* and not 10.*

Is there a way to solve this? Thank you!

lensman3

I don't think iptables will fix this. I think you need to look at the routing table. You want just the packets that go between your VPN networks to be tunneled. Everything else you want to go down the default route to the Internet and be masqueraded.

What does "/sbin/route -nv " say? I also thought that the VPN software was supposed to take care of routing issues.

Sorry I am not more help.

theVOID

Hey there

Yes, that's correct. The following is the routing table on Machine B.

machine:~ # route -nv
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.11.0.1 10.11.0.9 255.255.255.255 UGH 0 0 0 tun0
10.11.0.9 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 hso1
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 hso0



Somewhere there, we've missed something.

lensman3

See if you can put hso0 before hso1. That way packets go through hso1 before hso0. I didn't see where interface hso0 was in your first blog.

0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 hso0

I think the above route means all packets (0.0.0.0) coming from and going to go out hso0. The 10.11.* packets should go out through the tunnel.