Forwarding from VPN Clients not working

Dear All,

I have a OpenWrt 22.03.3 running on a Raspberry Pi 3b. My initial setup which works well is as follows,

Openwrt with Luci + OpenVPN + OpenSSL + easyrsa

I have since the day I set this machine up had 2 VPN clients loaded (tun9 and tun20) which I have used PBR rules to force traffic from certain devices to go out via either tun9 or tun20. This has worked well for over a year now.

This raspberry has a single ethernet connection and does not act as a firewall or a router apart from when handling VPN traffic which is its sole purpose on my internal network.

I recently wanted to setup a VPN Server which accepts connections from the internet alongside the two existing VPN client profiles. So I have forwarded port 1194 on my router to my OpenWRT, and the VPN service works (using tun100). My clients can connect, get assigned an IP and receive a gateway-redirect etc.

However the clients do not get internet access and can't access any local devices on my network.

I am fairly happy that my OpenVPN config is correct because I have basically migrated my working config from a shared hosting platform. So I think the issue is after OpenVPN with routing/forwarding/firewall in OpenWRT.
So I have checked and net.ipv4.conf.XYZ.forwarding is set to 1. I have added tun100 (my VPN server's TUN) to a new zone and tried enabling masquerade on the traffic going from this tun to my lan zone (which is effectively my lan+wan as I get internet access this way). I have tried numerous firewall rules and now I have effectively set everything now to allow all by default as a test.
I tried using PBR to force the traffic from my VPN clients (10.100.0.0/24) to go out via the lan zone but that did not work either.

But still if I run a traceroute from my client that has connected to my OpenWRT over LTE, then the traceroute drops at my OpenWRT's TUN interface's IP (10.100.0.1). The only device I can ping from my client is the OpenWRT's tun interface IP (10.100.0.1) and OpenWRT can ping my client on 10.100.0.2.

What am I missing here? If I am not missing something obvious then I must not have the right combination of firewall/masquerade/pbr rules set. Can someone give me a idiots guide to what I should have set to get basic traffic flowing from tun100 to lan where the traffic going to lan from tun100 should be masquerade (I guess)? I know there are a lot of basic guides out there, but they all assume you have a LAN interface and a separate WAN interface. I can't just enable masquerade on my lan interface so that would effect all traffic not just my OpenVPN server's clients.

Thanks in advance!

Turn on masquerading on the lan to see if this is the problem.

If this is the problem then you can instead of masquerading set a static route on your main router with the ovpn subnet routed to your dumb ap

2 Likes

Hi egc,

I didn't try it yet as I was afraid to break the clients on OpenWRT. But I just did as a test, and that enables traffic for my Server's Clients. Further it doesn't seem to have broken my clients? But I am surprised though that it does, because it looks like this,

VPN_US and VPN_SWE are my two VPN clients on the OpenWRT raspberry pi. So I am confused actually why enabling masquerade here even effects the traffic from my VPN Server as it is not listed here in the destination?

I tried creating new rules between lan -> VPNServer but that didnt take effect. So not sure why its taking effect on this rule but not the new one I created only for my VPNServer?

Yes the problem is that the machines on the LAN nor the LAN main router know that the gateway to get back to 10.100.0.0/24 is the Pi. Instead they use their default gateway-- the main router-- which tries to send the response unencrypted through the regular Internet, where it is lost.

If you turn on masquerade (on the lan zone, not the VPN), then VPN clients will be masqueraded from their 10.100 IPs into the Pi's LAN IP, which the LAN devices can return traffic to. However it will not be possible for a LAN device to initiate a connection to one of the clients without installing a port forward for every case.

Note that the routing table(s) must be correct first. The firewall rules can only restrict what would otherwise happen by routing-- they don't force a particular forward to happen.

Hi mk24,

Thanks. Yes I understand the basic principal of masquerade. But I guess what I am not understanding is how it is represented/configured in the screenshot I uploaded.

The way I read the top row in my screenshot is that traffic from my lan (internal network) being forwarded to wan (zone name containing VPN_SWE/tun9 and VPN_US/tun20) should be masqueraded.

But the traffic I want masqueraded is the traffic from my VPN (zone VPNServer/tun100) to my lan (internal network).

So I think what I am not understanding is how the configuration works

Ahh I think I am starting to see it. If I edit the top row, I see that the pop-up says, "This section defines common properties of "lan".".

So there is one entry per zone I just realised now. The ⇒ arrow makes it look like you can create multiple rules per zone. So I think what I was just doing was creating a new empty zone with no interfaces in it and setting the destination to lan and thinking it was being applied to my VPN going out via my LAN

I have since the day I set this machine up had 2 VPN clients loaded (tun9 and tun20) which I have used PBR rules to force traffic from certain devices to go out via either tun9 or tun20. This has worked well for over a year now.

Sorry, what does mean in single interface? Where is lan, and wan? How devices are connected?

Hi Ulmwind,

I mean the Raspberry Pi has a single physical connect (eth0 part of br-lan) that connects to my local network. This is also how it gets internet.

Confusingly I should rename the default "wan" zone. This simply contains my VPN Clients currently.

Physical connection:
Internet <-> Router <-> Switch <-> Raspberry Pi (OpenWRT)

Zones:
lan = br-lan (eth0)
wan = tun9, tun20 (openvpn clients)
VPNServer = tun100 (openvpn server)

(All other network equipment in my apartment connects physically to the Switch and either uses the Router as their gateway or the Raspberry Pi if they need to be connected out via one of the two VPN connections)

It is VERY strange configuration.

The problem is, that 'lan' has no route, default route is configured via 'wan'. But in your configuration there is 'lan' with route.

Correctly, in your case eth0 is 'wan', not 'lan', so devices connected to switch CAN NOT USE Raspberry Pi as gateway. OpenVPN-server on it runs successfully, in this case 'tun100' is 'lan', and forwarding 'lan'->'OpenVPN client' is performed.

The VPN tunnels are virtual interfaces and at least at level 3 you can treat them as Ethernet ports.

Since the Pi is not connected to the Internet directly, it doesn't have a conventional wan port. The closest thing is the two VPN clients which apparently tunnel to the Internet via a commercial service. It is also possible of course to reach the Internet untunneled by sending packets to the house's main router over the LAN, like any other LAN device would.

Additionally a port forward is in place so that clients can connect to the VPN server instance. From there they emerge from the tunnel the same as if the router were the house's main router. In other words the additional NATing and routing that occurs on the outside of the tunnel is not a consideration inside the tunnel at all.

This is not really a strange configuration other than that there are effectively three choices for an outgoing connection to the Internet instead of the usual one, so PBR and / or mwan will need to be involved.

1 Like

mk24, your description is spot on. Thats exactly how it is and then I use PBR as you suggested to route some devices out via the appropriate VPN.

Works great now! Thanks everyone for your help!

Great to hear it is solved.

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Thanks! :slight_smile:

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