Route openvpn client traffic through another openvpn client

[semiraue]

Hi all,

I have pfsense hosted on cloud VPS provider and different remote sites connected to it via OpenVPN. My networks are like this

VPN tunnel network – 192.168. 166.0/24

Remote Site openwrt gateway
	VPN IP – 192.168.166.11
	Local network – 192.168.77.0/24

Local home pc
	VPN IP – 192.168.166.2

I have added remote site OpenWrt gw (192.168.166.11) as one of the gateways in pfsense and added a static route to network 192.168.77.0/24. Now I can reach 192.168.77.0/24 from my local home pc (192.168.166.2) without any issues.

• Home pc has client-specific override profile in pfsense that force all traffic through pfsense.
• list itemInter-client communication disabeld.

But now I want to route home PC (192.168.166.2) traffic via remote OpenWrt gateway (192.168.166.11)
To do this I added a firewall rule on the OPENVPN interface (not the OpenVPN group interface) like below (for testing only for 1.1.1.1)

Action - PASS
Address Family - ANY
Protocol - ANY
Source Single host -  192.168.166.2
Destination Single host - 1.1.1.1
Gateway - Remote Site OpenWrt gateway (192.168.166.11)

But after adding this rule I cannot reach 1.1.1.1 from my home pc. when I do tcpdump on pfsense (vpn interface) I can see traffic comes to firewall dst to 1.1.1.1 from 192.168.166.2. But when I do tcpdump on remote OpenWrt gateway vpn interface I cannot see any traffic comes dst to 1.1.1.1. (tested using ICMP)

On remote site OpenWrt, I already allowed forwarding traffic from VPN interface to WAN. But since I cannot see any result on tcpdump I’m not sure that traffic reaching OpenWrt or not. How to troubleshoot/resolve this?

[viragomann]

@semiraue
Since the client PC and the OpenWRT which is the gateway are on the same L2 subnet, the traffic has not to pass pfSense.

If you want to do that, check Inter-client communication and add the route directly to the PC. You may also push it from the server in CSO by adding it into the advaced options box:

push "route 1.1.1.1 255.255.255.255 192.168.166.11"

For the default route, OpenVPN uses to split it in to lines, like:

push "route 0.0.0.0 127.255.255.255 192.168.166.11"
push "route 128.0.0.0 127.255.255.255 192.168.166.11"

[semiraue]

@viragomann Thanks,

But if I enable Inter-client communication I'm unable to do any firewalling since it bypasses the firewall if I'm not wrong?

Any other workaround for this? like NAT ?

[viragomann]

@semiraue
That's correct. But with disabled Inter-client communication you cannot get from one client to another one, what you try to do here.

Consequentially the simplest way to use the OpenWRT as default gateway on the PC is to connect directly to it.

With passing the traffic over the existing connections to pfSense, the only other way will be to run both connections on the different OpenVPN instances. So the traffic passes pfSense and you can apply firewall rules as well as routing rules to it.

[semiraue]

@viragomann said in Route openvpn client traffic through another openvpn client:

That's correct. But with disabled Inter-client communication you cannot get from one client to another one, what you try to do here.

Sorry, but I can reach to remote openwrt gateway and the local network of that with inter-client communication disabled. and I can apply any firewall rules.

you mean If I need to route traffic through a remote openwrt gateway, I should have that enabled?.

I don't understand how I'm able to reach even to OpenWrt local network but cannot go out from it.

[viragomann]

@semiraue said in Route openvpn client traffic through another openvpn client:

Sorry, but I can reach to remote openwrt gateway and the local network of that with inter-client communication disabled. and I can apply any firewall rules.

Can you access the OpenWRT's webGUI by calling its IP 192.168.166.11?
With the pfSense states flushed before, of course.

[stephenw10]

Hmm, this is an interesting question.

You are probably missing an iroute. You need to have a CSO defined for the OpenWRT site with 192.168.77.0/24 defined as a remote network so that the OpenVPN damon knows which client has that subnet behind it. Adding a static route for it should not be required. No should refining it as a gateway, though that would be required for policy routing.

Policy routing between two OpenVPN clients is not something I recall seeing before, I'm unsure how pf would handle that since the traffic is in and out of the same interface.

If you had two separate OpenVPN servers for this I would expect it to work though.

Steve

[semiraue]

@viragomann

@viragomann said in Route openvpn client traffic through another openvpn client:

Can you access the OpenWRT's webGUI by calling its IP 192.168.166.11?

yes, even after a reboot. also, I can access the LAN network behind it (192.168.77.0/24) from my home PC

[semiraue]

@stephenw10

@stephenw10 said in Route openvpn client traffic through another openvpn client:

You are probably missing an iroute. You need to have a CSO defined for the OpenWRT site with 192.168.77.0/24 defined as a remote network so that the OpenVPN damon knows which client has that subnet behind it

I think I already have this.

I create Client Specific Overrides for openwrt remote gateway and add 192.168.77.0/24 as a remote network.

Adding a static route for it should not be required

If I remove the static route I cannot reach the 192.168.77.0/24 network

Also, need to mention that OpenVPN server default config is Redirect Gateway disabled. I only enable it for my home pc (192.168.166.2)

[stephenw10]

You would need 192.168.77.0/24 defined as a remote network in the main OpenVPN server settings too.
That adds a route to the system routing table for 192.168.77.0/24 via the OpenVPN server. That is added when the OpenVPN server is started.
With that and the iroute you should not need any static routes.

That does not really affect the policy routing you are trying to achieve here though.

Have you tried adding that to the main openvpn group tab instead?

Steve

[semiraue]

@stephenw10 said in Route openvpn client traffic through another openvpn client:

You would need 192.168.77.0/24 defined as a remote network in the main OpenVPN server settings too.

The option "IPv4 Remote Network/s" only availble under CSO section. not the main OpenVPN server settings. Do I need to add it manually using the "Custom options" ?

Have you tried adding that to the main openvpn group tab instead?

Yes, I tried both OpenVPN group tab and OPENVPN firewall tab. I can see both rules work as same since I cannot reach 1.1.1.1 after adding the rule in either tab.

[stephenw10]

Yes, add it as a custom option:
route 192.168.77.0 255.255.255.0

The important thing to realise here is that you need both a system route to the OpenVPN daemon and an iroute within it.
That custom option will add the system route, check the routing table after openvpn has started.

The CSO will add the iroute, check the OpenVPN status page which will show routing to defined remote subnets.

That's the correct way to use those but it won't help with policy routing.

Steve

[semiraue]

@stephenw10 said in Route openvpn client traffic through another openvpn client:

Policy routing between two OpenVPN clients is not something I recall seeing before, I'm unsure how pf would handle that since the traffic is in and out of the same interface.

If you had two separate OpenVPN servers for this I would expect it to work though.

I set up another VPN server with tunnel network 192.168.117.0/24. then connected my local home PC to that VPN. now my network setup like below

VPN 1 tunnel network  – 192.168. 166.0/24

Remote Site openwrt gateway
	VPN IP – 192.168.166.11
	Local network – 192.168.77.0/24

VPN 2 tunnel network  – 192.168. 117.0/24

Local home pc
	VPN IP – 192.168.117.2

Then I create the below PBR rule on seconds VPN port (new) on the firewall.

Action - PASS
Address Family - ANY
Protocol - ANY
Source Single host -  192.168.117.2
Destination Single host - 1.1.1.1
Gateway - Remote Site OpenWrt gateway (192.168.166.11)

Still, I cannot go out via the remote openwrt gateway. ICMP simply fails. Any idea what I missing now?

[stephenw10]

Do you see it being routed in packet captures or the state table when you try to reach 1.1.1.1?

Where does it fail?