redirecting VPN Server to VPN Fusion client

[goldnet]

I'd like to route all traffic from an OpenVPN server client to the Wireguard client.

All the traffic keeps from the OpenVPN server keeps going to the internet instead of through the Wireguard client though.

I greatly appreciate any insight into what's missing or incorrect here.

 

[eibgrad]

I'm NOT a WG expert, but logically, in order to have the OpenVPN server's IP network routed over the WG client, the WG client must be serving as the default gateway.

As I understand it, the Allowed IPs field is NOT based on the source IP (that will be NAT'd over the tunnel anyway), but the *destination* IP(s) you want routed through the WG connection and over to the Peer.

IOW, it should be 0.0.0.0/0, which is effectively a default gateway setting. It routes *any* destination IP over the WG client, provided there isn't another more specific route that's known/available in the routing table (e.g., the private IP network).

Personally, I would use 0.0.0.0/1,128.0.0.0/1 for Allowed IPs, since these act as overrides rather than overlaying the current default gateway w/ 0.0.0.0/0

 

[goldnet]

I'm NOT a WG expert, but logically, in order to have the OpenVPN server's IP network routed over the WG client, the WG client must be serving as the default gateway.

As I understand it, the Allowed IPs field is NOT based on the source IP (that will be NAT'd over the tunnel anyway), but the *destination* IP(s) you want routed through the WG connection and over to the Peer.

IOW, it should be 0.0.0.0/0, which is effectively a default gateway setting. It routes *any* destination IP over the WG client, provided there isn't another more specific route that's known/available in the routing table (e.g., the private IP network).

Personally, I would use 0.0.0.0/1,128.0.0.0/1 for Allowed IPs, since these act as overrides rather than overlaying the current default gateway w/ 0.0.0.0/0

Thank you for your clarification about the Allowed IPs field.

If put "0.0.0.0/1,128.0.0.0/1" into Allowed IPs it will route all of the router's traffic to the WG client.

My goal is to only route traffic coming in from the OpenVPN server to the WG client.

How can I accomplish that please?

 

[eibgrad]

By default, the routing system only determines the routing based on the destination IP, NOT the source IP. IOW, it doesn't care how a packet got there, but only how to move it on to the next hop in its effort to get to the destination.

In order to be routed based on the source IP, you need PBR (policy based routing), such as the VPN Director w/ Merlin. You create rules w/ the VPN Director that tell the router that certain traffic based on the packet's source IP should be routed via the VPN as opposed to the WAN/ISP.

Unfortunately, I'm unfamiliar w/ the ASUS OEM firmware in this regard and whether it offers any such option. It's one of the reasons (among many others) ppl choose to use Merlin rather than the OEM firmware. Since you never mentioned any specifics regarding your hardware, I don't know if this is an option available to you.

 

[goldnet]

By default, the routing system only determines the routing based on the destination IP, NOT the source IP. IOW, it doesn't care how a packet got there, but only how to move it on to the next hop in its effort to get to the destination.

In order to be routed based on the source IP, you need PBR (policy based routing), such as the VPN Director w/ Merlin. You create rules w/ the VPN Director that tell the router that certain traffic based on the packet's source IP should be routed via the VPN as opposed to the WAN/ISP.

Unfortunately, I'm unfamiliar w/ the ASUS OEM firmware in this regard and whether it offers any such option. It's one of the reasons (among many others) ppl choose to use Merlin rather than the OEM firmware. Since you never mentioned any specifics regarding your hardware, I don't know if this is an option available to you.

I had everything working with the Merlin VPN director but I had to revert to stock firmware because the Merlin version was extremely unstable (I ran a ping to google.com continuously and the would often time out for no apparent reason). When I reverted to stock firmware the network was stable again. I switched back and forth several times between Merlin and stock a few times without changing anything else and the router would only keep timing out with Merlin.

The hardware is the "RT-AX88U PRO". I tried the earliest Merlin version available 388.3_0, as well as the latest 388.8_2 but the router was timing out pings the same way for both versions.

My goal is to accomplish the same thing as Merlin VPN director with Stock firmware.

I think using this static route ought to work, but it does not and but I don't understand what the error is yet:

172.16.0.0 is the "VPN subnet" setting of the OpenVPN server
10.143.81.64 is the "IP address" setting of the Wireguard client.

 

[eibgrad]

Remember what I said about the routing system. It's NOT looking at the source IP, only the destination IP. That static route you added is tell the routing system how to route to the 172.16.0.0/16 network AS A DESTINATION! It's worthless because that IP network is the one on which the router is running! IOW, you're already there at that destination. It's local to the router and thus will never be further routed across the WG tunnel or anything else. You need PBR (in the form of the VPN Director) to tell the routing system to route 172.16.0.0/16 as a source IP to some other destination.

 

[goldnet]

Remember what I said about the routing system. It's NOT looking at the source IP, only the destination IP. That static route you added is tell the routing system how to route to the 172.16.0.0/16 network AS A DESTINATION! It's worthless because that IP network is the one on which the router is running! IOW, you're already there at that destination. It's local to the router and thus will never be further routed across the WG tunnel or anything else. You need PBR (in the form of the VPN Director) to tell the routing system to route a 172.16.0.0/16 as a source IP to some other destination.

Yes, that makes sense. Thank you.

I haven't been able to find an interface for policy based routing in the stock firmware.

Can I accomplish policy based routing for this using iptables commands in a script on the router?

 

[eibgrad]

Could you implement your own PBR? Technically, yes. But it's a bit complicated to set up and manage (it's more than one or two lines of coding). Even if you could, I'm not certain how easy it's going to be to manage *any* kind of scripting w/ the OEM firmware. Typically such capabilities are VERY limited, assuming it's capable at all. Again, that's why users turn to Merlin, which makes using your own scripting much, much easier. But at that point, you already have the VPN Director for such purposes.

I understand your dilemma. But at this point determining what's causing your stability issues w/ Merlin is probably the better approach.

 

[goldnet]

Could you implement your own PBR? Technically, yes. But it's a bit complicated to set up and manage (it's more than one or two lines of coding). Even if you could, I'm not certain how easy it's going to be to manage *any* kind of scripting w/ the OEM firmware. Typically such capabilities are VERY limited, assuming it's capable at all. Again, that's why users turn to Merlin, which makes using your own scripting much, much easier. But at that point, you already have the VPN Director for such purposes.

I understand your dilemma. But at this point determining what's causing your stability issues w/ Merlin is probably the better approach.

OK, I am hearing substantial reasons that the stock firmware is probably not a good path for my goal. Thank you for that.

The issue with Merlin is that web pages randomly fail to load and pings to google.com just time out randomly.

Where would be the best place to start identifying the cause of that?

 

[eibgrad]

When pages fail to load or become unpredictable, it's often an MTU issue. This is esp. true with VPNs since you're nesting one protocol inside another. If the VPN is using too big of an MTU, it can exceed the max MTU of 1500 and cause fragmentation.