“Allow LAN Traffic” not working for incoming traffic from different subnet about desktop HOT 12 CLOSED

Like I said, it's possible we may change in the future :) It's definitely a legitimate argument :)

If one wants precise control, one can disable “Allow LAN Traffic” and add one’s desired subnets to the whitelist.

This would be a bit strange as PIA would end up creating routes that are never used, as the on-link routes for those hosts would override the route for the subnet; so the added route would just be ignored - in effect you're only adding the subnet to the bypass to get the firewall rules, not the routes.

Anyway i'll close this issue now, if you want to continue discussion i think our subreddit might be a better place for it, that way other users can more easily join in too.

Thanks for your feedback! :)

from desktop.

I noticed that “Allow LAN Traffic” affects both the PF firewall configuration and the kernel extension logic. What is the relation between the PF firewall and the kernel extension?

from desktop.

@fumoboy007 We have a new feature in 2.1 to deal with this situation. Add computer C's subnet (in CIDR notation) to the split tunnel - you will see this option under "Add IP Address" in the split tunnel window. You should now be able to ping freely between the two subnets.

As to why you're able to ping A from C while the split tunnel is enabled - this is probably because the split tunnel adds a default "bound route"; this route will cause outgoing packets to be routed through the physical gateway so long as the source ip is that of the physical interface (which it will be in the ICMP response).

The relationship between the kerrnel extension and the PF firewall is a tricky one - the kernel extension has its own custom firewall so some firewall rules from the PF firewall must be re-created. You can see it here: https://github.com/pia-foss/desktop-mac-network-kext/blob/master/PiaKext/PiaKext.c#L700-L814

from desktop.

@fumoboy007 Let me know if that solves your problem and i can go ahead and close this issue 😄

from desktop.

We have a new feature in 2.1 to deal with this situation. Add computer C's subnet (in CIDR notation) to the split tunnel - you will see this option under "Add IP Address" in the split tunnel window. You should now be able to ping freely between the two subnets.

I shouldn’t need to do this since Computer C has a private IP address, so it should be whitelisted when “Allow LAN Traffic” is enabled, right?

As to why you're able to ping A from C while the split tunnel is enabled - this is probably because the split tunnel adds a default "bound route"; this route will cause outgoing packets to be routed through the physical gateway so long as the source ip is that of the physical interface (which it will be in the ICMP response).

Ah, I see the additional route in netstat -rn. Forgive my ignorance… what is the purpose of this route and why is it only added when “Split Tunnel” is enabled?

The relationship between the kerrnel extension and the PF firewall is a tricky one - the kernel extension has its own custom firewall so some firewall rules from the PF firewall must be re-created. You can see it here: https://github.com/pia-foss/desktop-mac-network-kext/blob/master/PiaKext/PiaKext.c#L700-L814

Why does the kernel extension duplicate the PF rules? Shouldn’t it just be focused on the additional Split Tunnel rules?

from desktop.

@fumoboy007 Our implemenation of "Allow LAN" only allows communication between on-link hosts. Your other host (C) is on another link, so can only be accessed via a hop through your router. When the VPN is active it takes over the default route so even private IPs that are not on-link would go through the VPN - and fail to reach the correct host.

Your issue is quite a common one and so we introduced the ip-based splittunnel feature to address it, it works by creating routes out the physical interface for the subnets you specify. It's also useful for public Ips too, and can be used for example, to manage cloud servers even when that server is running our VPN.

Forgive my ignorance… what is the purpose of this route and why is it only added when “Split Tunnel” is enabled?

This route allows us to use source-based routing - when this route exists any packet whose source ip matches the physical interface will get routed through that physical interface. This is how our split tunnel 'bypass' feature works.

Why does the kernel extension duplicate the PF rules? Shouldn’t it just be focused on the additional Split Tunnel rules?

Because the PF-firewall does not give us enough fine-grained control, unfortunately. It does not allow us to block/allow based on PID. So instead we open a hole in the PF firewall ("anything with the physical sourrce ip is allowed") and then apply finer-grained rules in the kext to exactly allow/block what we need - unfortunately this requires us to re-implement some of the same rules from the PF firewall.

from desktop.

Thanks for the explanations! I think I understand now.

1. The kernel extension needs to duplicate the firewall rules because the PF firewall is effectively disabled for outgoing traffic when “Split Tunnel” is enabled.

2. The firewall isn’t relevant to this issue; the firewall is working correctly in the context of “Allow LAN Traffic”. This issue is caused by a routing problem.

3. When “Split Tunnel” is disabled, all outgoing traffic is routed through the tunnel interface. Even though the ICMP echo request from the LAN is successfully received, the ICMP echo reply is not successfully sent because it is routed through the tunnel interface.

4. When “Split Tunnel” is enabled, an extra bound route is added for the regular interface, which allows the kernel extension to route outgoing traffic from a whitelisted process through the regular interface by explicitly setting the source address to that of the regular interface (so-called source-based routing, which is the opposite of the default destination-based routing). Due to the bound route, the ICMP echo reply will be routed through the regular interface because the socket is bound to the address of the regular interface, which means packets would be routed using source-based routing.

5. Even with the extra bound route, outgoing LAN traffic originating from this computer would be routed through the tunnel due to destination-based routing. The existing source-based routing mechanism in the kernel extension is used to solve this problem as part of the v2.1 feature to whitelist addresses.

How would we fix this issue for WireGuard where “Split Tunnel” is not supported? Could we add explicit routes for the private addresses (i.e. route destination addresses 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 to the regular interface)?

from desktop.

1. The firewall is disabled for outgoing traffic whose source ip is the physical interface (such as "bypass" apps). These packets would otherwise be dropped as they're not on the tunnel.

2. Correct :)

3. Bingo.

4. Mostly correct. I believe the echo reply is allowed out because the incoming packet had its destination set to the physical interface. This source/dest is just swapped for the echo reply; and the physical source will cause it to match the bound route when going out.

5. I think it's more that the default source ip for out-going packets is the local VPN ip. However, if you explicitly set the source ip of an out-going packet then it will follow the bound route, e.g ping <other lan subnet host> -S <physical interface ip>

Check out the 2.2 beta, it has complete WireGuard support for the split tunnel feature 👍

from desktop.

Sorry, i misunderstood what you were saying in 5. The packets headed to the other LAN subnet get routed out the physical interface because of the more specific subnet routes that get added via the ip split tunnel feature. It still uses destination based routing, it just happens that the destination leads out the physical gateway, rather than the VPN.

from desktop.

1. The firewall is disabled for outgoing traffic whose source ip is the physical interface (such as "bypass" apps). These packets would otherwise be dropped as they're not on the tunnel.

Oh, I see. I thought the order of filtering was firewall first and then kernel extension but it’s the other way around.

4. Mostly correct. I believe the echo reply is allowed out because the incoming packet had its destination set to the physical interface. This source/dest is just swapped for the echo reply; and the physical source will cause it to match the bound route when going out.

I think that’s what I wrote too?

Sorry, i misunderstood what you were saying in 5. The packets headed to the other LAN subnet get routed out the physical interface because of the more specific subnet routes that get added via the ip split tunnel feature. It still uses destination based routing, it just happens that the destination leads out the physical gateway, rather than the VPN.

Oh, I see the extra route. Why don’t we just always do that for all the private addresses when “Allow LAN Traffic” is enabled?

Check out the 2.2 beta, it has complete WireGuard support for the split tunnel feature 👍

Yay!!!

from desktop.

Oh, I see the extra route. Why don’t we just always do that for all the private addresses when “Allow LAN Traffic” is enabled?

We could, but (1) A user may want to expose his system to on-link hosts but not to every host on a WAN - some WANs can be huge. (2) Allowing precise control over which off-link subnets can see your system is a more cautious and safer default. Implementing this via ip-based split tunnel also has the benefit of allowing other use cases, beyond LAN subnet access.

We may revisit this, but I think we're pretty happy with the current trade-offs.

from desktop.

By my intuition, “Allow LAN Traffic” implies any LAN traffic, which includes any reachable private address. I’m not sure many people would read “Allow LAN Traffic” as “Allow Same-Subnet LAN Traffic”.

The precise control you speak of can still happen even if we change the behavior of “Allow LAN Traffic” to mean “any reachable private address”. If one wants precise control, one can disable “Allow LAN Traffic” and add one’s desired subnets to the whitelist.

I am not advocating for removing the address whitelisting feature; I am just suggesting that we change the behavior of “Allow LAN Traffic” to match one’s intuition. Either way, my issue is adequately solved in v2.2, so feel free to close the issue if you disagree. However, I think my suggestion would prevent similar questions from being raised in the future.

from desktop.