Poking one small hole thru "Block Non-VPN traffic"

My current VPN setup is an always-on VPN, with "Block Non-VPN traffic" enabled, and the VPN in "Global Proxy" mode. I like this setup due to its simplicity, as I place a high priority on not leaking traffic outside the VPN.

Unfortunately, the VPN endpoint I use blocks outbound traffic on port 465 and 587, so I have come to need for traffic to my mail provider to bypass the VPN.

I understand I may be able to accomplish this via changing from "Global Proxy" mode to "Based on the Target Domain or IP." And I will investigate that, however, what I am looking to do with this question is understand why my attempted solution doesn't work.

The following is an excerpt of what's visible in Luci > Network > Firewall > Traffic Rules:

As you can see, I've added a rule called "tailscale outbound" to allow traffic destined to port 41641 on any host on my uplink network (172.x.x.0/24) to bypass the VPN, so that Tailscale nodes behind my GL-MT3000 can talk to Tailscale nodes which live on the uplink network. This works, which I verified by tailscale ping - without that rule, Tailscale traffic destined for nodes on the uplink network goes over the VPN, but with that rule, Tailscale traffic destined for nodes on the uplink network goes directly to the node in question.

Below the Tailscale rule, you can see that I've added a rule called "mail submission outbound," attempting to bypass the VPN for TCP traffic destined to port 465 on any host on my mail provider's network (185.x.x.0/24). But this doesn't work, and my question is why not?

Hi,

I'm new to gl.inet and LuCi. I'm still not very familiar with how it works, but maybe I can help.

I think you've set up access policies and what you need is routing. But as far as I know, gl.inet/LuCi doesn't have port-based routing capabilities.

The 185.x.x.x/24 IP addresses are a public range. So, I take it you're only routing private traffic in Tailscale? And the 185.x.x.x/24 address would be going out locally.

Hi, thanks for your interest.

Yes, my Tailscale network is a private overlay network, no traffic destined for the internet goes over Tailscale and there's no exit node.

And yes :slight_smile: what I was attempting to do with the above setup is have TCP traffic destined for port 465 on 185.x.x.0/24 bypass my always-on VPN connection and go out via the un-VPNed uplink.

What I don't understand is why the rule for Tailscale works, but the rule for 185.x.x.0/24 port 465 doesn't.

I'm not entirely sure how Tailscale works, but according to the manual, you specify a device and configure the routes to the networks you want to reach. You can also specify whether you want it to be an 'exit node', an exit to the internet. If that option isn't enabled, your internet traffic should be local. Tailscale - GL.iNet Router Docs 4

To be sure where the traffic is being sent, you could run a traceroute to an IP of 185.x.x.x and make sure if it goes through Tailscale or locally.

You could try configuring the route to force traffic to the destination 185.x.x.x/24 nexthop gateway

I think I wasn't clear.

Tailscale here is a red herring - my actual question does not have anything to do with Tailscale. The "tailscale outbound" rule is only mentioned as an example of a similar pre-existing rule which is working fine.

I'm not trying to send any traffic over Tailscale and am in fact not concerned with Tailscale at all, it's just that the "tailscale outbound" rule already existed before I tried to set up the "mail submission outbound" rule, and "tailscale outbound" works, while "mail submission outbound" does not.

The "tailscale outbound" rule allowing traffic destined for Tailscale nodes in 172.x.x.0/24 port 41641 to bypass the VPN, seems very similar to the "mail submission outbound" rule, which was intended to allow traffic destined for email servers in 185.x.x.0/24 port 465 to bypass the VPN.

So, what I don't understand is why the "tailscale outbound" rule works, while the "mail submission outbound" rule does not.

The only difference I can see, is that 172.x.x.0/24 is my uplink network (the GL-MT3000 is plugged directly into this network), whereas 185.x.x.0/24 is a public internet address. Perhaps the 'wan' zone refers only to the uplink network, not the entire internet?

You could try configuring the route to force traffic to the destination 185.x.x.x/24 nexthop gateway

I may indeed end up attempting to solve this with a static route, I'm just trying to understand why the "mail submission outbound" traffic rule doesn't work, when it seems so similar to the "tailscale outbound" traffic rule.

I don't know how Tailscale works and I have seen that there is a GUI configuration and another CLI that is not always visible.

In any case, private traffic is not the same as public traffic. And if there's no route to indicate where it should go, an access policy won't be of any use.

But I don't understand why that public traffic isn't working for you, since the Glinet router already provides Internet access by default. It shouldn't be a problem, unless a VPN is forcing a 0.0.0.0/.0 route.

Hmm, maybe this is the problem?

The VPN does specify 0.0.0.0/0... which I guess would not apply to reserved IP addresses, which include the 172.x.x.0/24 uplink network :thinking:

Oooh!! If route 0.0.0.0/0 exists, it means everything is sent there :hot_face:

If you don't want the internet to run through the tunnel, you just need to have the private network on your other end configured.

That's why I told you that if you ran a traceroute, the different hops would show which path it would follow (local or through vpn to the other end)

But if so, you shouldn't have internet. Not just email 185.x.x.x