block-local doesn't work

[efef]

It seems in the latest Appstore macOS app the block-local feature, that often is pushed by the eduVPN server, doesn't work.
This feature should block access to local network resources when VPN has been turned on.

This feature should have been fixed in Tunnelkit:
passepartoutvpn/tunnelkit#96

In eduVPN App-log I read now:
2020-07-08 10:37:25.185 DEBUG OpenVPNSession.handleControlMessage():956 - Received PUSH_REPLY: "PUSH_REPLY,block-outside-dns,dhcp-option DNS 192.87.106.106,dhcp-option DNS 192.87.36.36,dhcp-option DNS 2001:610:1:800a:192:87:106:106,dhcp-option DNS 2001:610:3:200a:192:87:36:36,explicit-exit-notify 1,redirect-gateway def1 ipv6 block-local,tun-ipv6,route-gateway 145.90.228.129,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 2001:610:450:40::2:102d/112 2001:610:450:40::2:1,ifconfig 145.90.228.175 255.255.255.192,peer-id 17,cipher AES-256-GCM"
2020-07-08 10:37:25.188 INFO OpenVPNTunnelProvider.sessionDidStart():525 - Gateway: ["IPv4", "IPv6", "blockLocal"]

[ghost]

Is this working properly on iOS? Is this working in Passepartout?

Make sure you are testing with a server where this is enabled... you can see it in the PUSH_REPLY value block-local. So not "blockLan" as it is called in eduVPN.

[johankool]

This issue seems to happen only on macOS 10.14. On 10.15 it works as expected.

Noticed this difference in the logs between the macOS versions:

10.14 gives in the log:

2020-07-10 13:18:33.694 INFO OpenVPNTunnelProvider.bringNetworkUp():750 - Block local: Suppressing IPv4 route default/32
2020-07-10 13:18:33.694 INFO OpenVPNTunnelProvider.bringNetworkUp():750 - Block local: Suppressing IPv4 route default/32
2020-07-10 13:18:33.694 INFO OpenVPNTunnelProvider.bringNetworkUp():765 - Block local: Suppressing IPv6 route default/128
2020-07-10 13:18:33.694 INFO OpenVPNTunnelProvider.bringNetworkUp():765 - Block local: Suppressing IPv6 route default/128

10.15 gives in the log:

2020-07-10 13:35:21.296 INFO OpenVPNTunnelProvider.bringNetworkUp():750 - Block local: Suppressing IPv4 route 192.168.178.0/25
2020-07-10 13:35:21.296 INFO OpenVPNTunnelProvider.bringNetworkUp():750 - Block local: Suppressing IPv4 route 192.168.178.128/25
2020-07-10 13:35:21.296 INFO OpenVPNTunnelProvider.bringNetworkUp():765 - Block local: Suppressing IPv6 route fe80::/65
2020-07-10 13:35:21.296 INFO OpenVPNTunnelProvider.bringNetworkUp():765 - Block local: Suppressing IPv6 route fe80::8000:0:0:0/65

[ghost]

So, can this issue be closed? It works properly in macOS >= 10.15?

[ghost]

Just tested it on macOS 11 with eduVPN app and block-local does NOT work with the nl.eduvpn.org server, i.e. LAN traffic is still allowed while connected to the VPN.

[mkoelewijn]

This does not seem to work with the latest version (Version 2.1.9 (1088)) on 11.2 (Big Sur)

2021-02-08 15:58:51.155 INFO OpenVPNTunnelProvider.bringNetworkUp():750 - Block local: Suppressing IPv4 route default/32
2021-02-08 15:58:51.156 INFO OpenVPNTunnelProvider.bringNetworkUp():750 - Block local: Suppressing IPv4 route default/32
2021-02-08 15:58:51.156 INFO OpenVPNTunnelProvider.bringNetworkUp():765 - Block local: Suppressing IPv6 route default/128
2021-02-08 15:58:51.156 INFO OpenVPNTunnelProvider.bringNetworkUp():765 - Block local: Suppressing IPv6 route default/128

[roop]

I now have a native IPv6 internet connection working with my ISP. I can run "ping6 google.com" and have that work.

I tested with Let's Connect! for macOS v3.0.1 from two Macs: A MacBook Air running macOS 10.15.7 (Catalina) and a Mac mini running macOS 12.3.1 (Mojave). (I don't have a machine running macOS 11.x (Big Sur).)

In both cases:

• Before connecting, I could ping the other machine (connected to the same wifi router) through IPv4. With IPv6, I could ping6 only if I provide the interface that should be used to access it.
• After connecting to nl.eduvpn.org, I could not ping the other machine (connected to the same wifi router) through IPv4. With IPv6, I could ping6 only if I provide the interface that should be used to access it.
• No "default/32" / "default/128" stuff was seen in the log. Log from the Mac mini looked like:

  Block local: Suppressing IPv4 route 192.168.1.0/25
  Block local: Suppressing IPv4 route 192.168.1.128/25
  Block local: Suppressing IPv6 route fe80::/65
  Block local: Suppressing IPv6 route fe80::8000:0:0:0/65
  

So it looks like block local is working fine on Catalina and Mojave.

[roop]

The PUSH _REPLY from nl.eduvpn.org contains "block-local,route 0.0.0.0 0.0.0.0". I assume that means the VPN interface should be the default route for everything, including local addresses.

If that's the case, we could set includeAllNetworks to ensure all traffic flows through the tunnel (instead of running netstat and figuring out the routes). (If block-local is NOT specified, we could set includeAllNetworks and also set excludeLocalNetworks). Edit: includeAllNetworks and excludeLocalNetworks are APIs to be set on the app side, not on the tunnel side, so they are not useful for this use case.

@fkooman: Maybe we can make use of the server API to figure out if everything is meant to be sent to the VPN (default_gateway), and whether local LAN should be blocked or not (no server API currently exists, I think) and then use includeAllNetworks and excludeLocalNetworks to set that up? (I still need to investigate if those work as documented.)

[roop]

I installed macOS 11.6.7 (Big Sur) on an external SSD and booted my Mac mini off that disk. I tested with Let's Connect! for macOS v3.0.1. The behaviour is similar: IPv4 local LAN is not pingable when connected to nl.eduvpn.org through OpenVPN. Log entries look similar as well.

So it looks like block local is working in Big Sur as well.

[efef]

On Monterey with latest Appstore client (3.0.2) and connected with nl.eduvpn.org I can't connect to another device in same RFC1918 iprange.

However when I connect my laptop on a public ip-range directly, next connect nl.eduvpn.org . The blockLAN feature doesn't seem to work. So my conclusion is it might only work on RFC1918 ipranges

[ghost]

This works for me now! I only tested when using 192.168.178.X IP range for clients, not public IP addresses as done by @efef above.