OpenVPN won't work WITHOUT Masquerading

Installing and Using OpenWrt Network and Wireless Configuration
1

Hello,

I have been struggling with an issue for days and really do need some help please. For a couple of years I have been using OpenVPN on OpenWRT 15 to connect my home office to our work office LAN. We use IP telephones, so cannot use NAT / Masquerading.

Recently we deployed a new OpenVPN server at work, and I have upgraded my home router to 18.06. Router is TP-Link TL-WR1043N/ND v2.

Everything works fine - Tunnelblick client to new OpenVPN server, the OpenWRT OpenVPN client connects fine too, and from the router command line I can ping and SSH to everything in the office.

But from my Mac on the client LAN, I can only reach the office network IF masquerading is on. Unfortunately, masquerading breaks the IP telephony, so I need a full routed solution. If I turn masquerading off, nothing works. From the Mac, I can ping tun0 on the local router, but not tun0 on the remote server at the office.

I just assume I've got something wrong in the firewall, but I can't figure out what it is. Would very much appreciate some assistance with this one:

10.88.88.241[My Mac] --> [eth0: 10.88.88.10, OpenWRT/OpenVPN, tun0: 192.168.255.2] ->> [ Internet ] ->> [tun0: 192.168.255.1, OpenVPN server, eth0: 10.66.66.77] --> 10.66.0.0 [Office LAN]

Would appreciate any pointers anyone can give ...

Please see next message for a link to a document with all configs and test results.

Thanks,

2

Here's a link to a doc which lays out the configs, etc, a little more nicely...

OpenVPN on OpenWRT won't work WITHOUT masquerading

3

May be I am wrong, but.
It seems server side LAN(10.66.0.0) hosts does not know route to you home LAN(10.88.88.0)

In OpenVPN server config should be:

push "route 10.66.66.0 255.255.255.0"     # I think, this line is already present in VPN server config
route 10.88.88.0 255.255.255.0            # But this line is absent

Besides, on the server side should exists ccd(client config directory) with filename of your certificate.
With content

iroute 10.88.88.0 255.255.255.0

Do not miss "i" in iroute.

With this config all server side hosts should see all home LAN hosts and vice versa.
if I didn't confuse anything :wink:

All this will works only if OpenVPN server host is default gateway in your office LAN.

If OpenVPN server is not office LAN default gateway, then you should add route on the default getaway host.
Something like this

ip route add 192.168.255.0/24 via 10.66.66.77
ip route add 10.88.88.0/24 via 10.66.66.77

if I didn't confuse anything again :wink:

4

Really appreciate your taking the time to respond - thank you.

Here is the ccd file on the server:
root@repo:/etc/openvpn# cat ccd/callum-home
ifconfig-push 192.168.255.43 255.255.255.0
iroute 10.88.88.0 255.255.255.0

Here is the routing table on the server:

root@repo:/etc/openvpn# netstat -rn
Kernel IP routing table

Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.66.66.1 0.0.0.0 UG 0 0 0 eth0
10.66.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
10.88.88.0 192.168.255.2 255.255.255.0 UG 0 0 0 tun0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker_gwbridge
192.168.255.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0

Here is the routing table on the client router:
root@OpenWrt:~# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 100.69.0.1 0.0.0.0 UG 0 0 0 eth0.10
9.1.1.0 192.168.255.1 255.255.255.0 UG 0 0 0 tun0
10.66.0.0 192.168.255.1 255.255.0.0 UG 0 0 0 tun0
10.88.88.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan
100.69.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0.10
172.16.1.0 192.168.255.1 255.255.255.0 UG 0 0 0 tun0
192.168.255.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0

So, we can see that the server has a correct route to 10.88.88.X via tun0, and the client router has a correct route to 10.66.XX.XX via its tun0

From the client router OpenWRT I can ping and SSH any host on the server's network, so we know the server end definitely has a return path.

I'm certain that without masquerading, the incoming client traffic is not getting to the OpenVPN tun0..

5

Ok, but what about routes on 10.66.66.1 ?

Because this is your default gateway in office LAN.

6

The office default gateway will never be used by the OpenVPN clients. OpenVPN is only to reach the office systems, such as the telephones.

The problem is definitely that packets from the 10.88.88.X network at my home do not get to the OpenVPN vpn connection on OpenWRT unless masquerading is on. I know this because I ran a lan trace (using tcpdump) on the OpenVPN server at the office.

So routes in the office's default gateway won't be affecting this problem as far as I can work out.

7

Ok, you created special zone for VPN.

Try to move it in one zone:

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option network 'lan vpn'

And temporaly remove zone VPN

1 Like
8

Good idea. I tried that.

image

Exactly the same result. Can ping across the VPN from client router to server but not from Mac on client network.

Does that mean the problem is not caused by the firewall?

9

Are you sure, that routing gateway is 192.168.255.2?

1 Like
10

Well spotted. I spotted that too, about an hour ago and noticed that tun0 on the client router was not getting the .43 address specified in the ccd client file on the server. Looking closer, the server.conf file was missing the client-config-directory line. I added it and now everything works! Still don't understand why that made a difference. The server routes were still correctly pointing to the .2 address that did get allocated. And strangely enough, the route are the server end for 10.88.88.0 is still pointing to .2! But it works, so I'm going to leave it alone.

Thanks to yourself and oslyack For giving me the pointers. They really helped.

11

iroute doesn't work without client-config-dir, which is critical.

Omitting gateway parameter results in automatically selecting first address from the range:

1 Like
12

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.