Disable IPv6 when connected to VPN

[SomeWhereOverTheRainBow]

Use a VPN that supports IPv6

Or manually disable the ipv6 per client. For example, if it is a windows computer using the tunnel, just disable ipv6 on that single client.

 

[Frank Monroe]

Or manually disable the ipv6 per client. For example, if it is a windows computer using the tunnel, just disable ipv6 on that single client.

Unfortunately, there is no option to do this on some streaming devices.

What I have been doing for over a year is use parental controls to block internet traffic for the device. Then issue the following to re-enable IPv4 traffic:

iptables -D FORWARD -i br0 -m mac --mac-source xx:xx:xx:xx:xx:xx -j DROP

I"m sure there are better solutions. But this has worked for me until a better solution is found.



EDIT: fixed typo

 

[SomeWhereOverTheRainBow]

Unfortunately, there is no option to do this on some streaming devices.

What I have been doing for over a year is use parental controls to block internet traffic for the device. Then issue the following to re-enable IPv4 traffic:

iptnbles -A FORWARD -i br0 -m mac --mac-source xx:xx:xx:xx:xx:xx -j DROP

I"m sure there are better solutions. But this has worked for me until a better solution is found.

Same should be able to be done for both the input and forward of the vpn interface. For example

ip6tables -I INPUT -i tun?? -j DROP
ip6tables -I FORWARD -i tun?? -j DROP
ip6tables -I OUTPUT -o tun?? -j DROP

Obviously the ?? Need to be adjusted to the correct number for the tun interface.

 

[Frank Monroe]

Same should be able to be done for both the input and forward of the vpn interface. For example

ip6tables -A INPUT -i tun?? -j DROP
ip6tables -A FORWARD -i tun?? -j DROP

Obviously the ?? Need to be adjusted to the correct number for the tun interface.

Sorry, I. probably confused you. The command I actually issue is: iptables -D FORWARD -i br0 -m mac --mac-source xx:xx:xx:xx:xx:xx -j DROP to re-enable IPv4 traffic after its disabled by putting the device in the parental control block list. The prior post had a significant typo.

 

[SomeWhereOverTheRainBow]

Sorry, I. probably confused you. The command I actually issue is: iptnbles -D FORWARD -i br0 -m mac --mac-source xx:xx:xx:xx:xx:xx -j DROP to re-enable IPv4 traffic after its disabled by putting the device the parental control block list. The prior post had a significant typo.

No confusion. The rules I listed were for ensuring ipv6 would be blocked at the tun interface of the vpn client in question for the OP.

 

[pmcarrion]

Okay ditch those lines and try

block-ipv6 in the same config, but place it at the bottom of the .ovpn or .conf file

The script didn't fail, but it made my network sluggish and IPv6 wasn't blocked.
I think this would work well on a desktop client.

You are going to save yourself trouble by disabling IPv6 completely. It is disabled by default on Asus routers anyway.

You're right, I'll just disable it until the router's VPN client supports IPv6.

You'd probably need to implement it through an openvpn-event script, adding firewall rules to drop outbound IPv6 traffic. This might cause a problem however for your network clients that may be attempting to use IPv6 if they already had an IPv6 allocated to them.

I noticed this with some IoT devices that stop working all of a sudden.
Unfortunately, the combination of IPv6 + VPN at the router level is not ready for mass adoption.
IPv4 goes behind NAT, so it's fairly simple to redirect at the router level.
IPv6 would require pushing new IPv6 addresses from the VPN to the network clients and force releasing the ISP ones. This is much more complicated as there's no NAT in IPv6.
Releasing an IPv6 address usually involves physically disconnecting devices from the network (turn off Wi-Fi, reconnect Ethernet cables or forcing a power cycle).

Use a VPN that supports IPv6

My VPN supports IPv6. The router's VPN client doesn't.

 

[pmcarrion]

Or manually disable the ipv6 per client. For example, if it is a windows computer using the tunnel, just disable ipv6 on that single client.

Only computers allow this, so most devices would be left out.

Same should be able to be done for both the input and forward of the vpn interface. For example

ip6tables -I INPUT -i tun?? -j DROP
ip6tables -I FORWARD -i tun?? -j DROP
ip6tables -I OUTPUT -o tun?? -j DROP

Obviously the ?? Need to be adjusted to the correct number for the tun interface.

I'll test this. Thanks.

 

[Frank Monroe]

You're right, I'll just disable it until the router's VPN client supports IPv6.

I realize I'm probably in the minority here, but not all of us can disable IPv6 or even want to due to services that require it. I guess for now, I will use the solution I have been using.

 

[eibgrad]

Ideally, if the OpenVPN client supported IPv6, you could bind those same IPv4 clients to the VPN w/ the VPN Director and solve the problem. But even so, the solution is actually quite simple, and requires no changes to the OpenVPN client. As I suggested before (and Merlin reiterated), it's a simple matter to create ip6tables rules to block those same IPv6 devices.

ip6tables -I FORWARD -m mac --mac-source 00:01:02:03:04:05 -j REJECT

You could either create a firewall-start script if you want this enforced 24/7, or else an openvpn-event script to add and remove them as the routes come up and down, respectively.

A more sophisticated solution would examine the VPN Director rules and consider blocking based on the source IPs defined therein. But it's NOT going to be perfect since those same rules might contain remote/destination IPs as well, thereby further limiting the scope of those rules. IOW, there's no easy way to map those remote/destination IPv4 IPs to their IPv6 equivalents and have only those be blocked over the WAN.

No, I don't have any such script at hand. But if you take the firewall-start approach, it should be pretty easy to do.

 

[SomeWhereOverTheRainBow]

My VPN supports IPv6. The router's VPN client doesn't.

Your solution should be to delete all ipv6 push routes from your vpn providers ovpn file then. That is the problem. When ever you load the ovpn file it is creating the suggestion to allow ipv6 traffic, but the router is not wanting to establish the connection you need to send your ipv6 client traffic through the tunnel. If you delete the push routes for ipv6, then it should in theory stop creating the connection. Thus ipv6 traffic dead ends outside the tunnel.

 

[SomeWhereOverTheRainBow]

Ideally, if the OpenVPN client supported IPv6, you could bind those same IPv4 clients to the VPN w/ the VPN Director and solve the problem. But even so, the solution is actually quite simple, and requires no changes to the OpenVPN client. As I suggested before (and Merlin reiterated), it's a simple matter to create ip6tables rules to block those same IPv6 devices.

ip6tables -I FORWARD -m mac --mac-source 00:01:02:03:04:05 -j REJECT

You could either create a firewall-start script if you want this enforced 24/7, or else an openvpn-event script to add and remove them as the routes come up and down, respectively.

A more sophisticated solution would examine the VPN Director rules and consider blocking based on the source IPs defined therein. But it's NOT going to be perfect since those same rules might contain remote/destination IPs as well, thereby further limiting the scope of those rules. IOW, there's no easy way to map those remote/destination IPv4 IPs to their IPv6 equivalents and have only those be blocked over the WAN.

No, I don't have any such script at hand. But if you take the firewall-start approach, it should be pretty easy to do.

That is a great solution if you only require to go client by client, but is there a one size fits all clients rule?

 

[eibgrad]

That is a great solution if you only require to go client by client, but is there a one size fits all clients rule?

Not sure what you mean. You could certainly block ALL IPv6 clients universally, but that's a pretty crude solution.

ip6tables -I FORWARD -j REJECT

 

[SomeWhereOverTheRainBow]

Not sure what you mean. You could certainly block ALL IPv6 clients universally, but that's a pretty crude solution.

ip6tables -I FORWARD -j REJECT

No, an example of blocking it since the vpn provider is setting up routes for it in the tunnel, but it appears that clients are not using it properly hence the need to block access to it via firewall.

 

[eibgrad]

No, an example of blocking it since the vpn provider is setting up routes for it in the tunnel, but it appears that clients are not using it properly hence the need to block access to it via firewall.

I don't think that's the problem. In fact, the OpenVPN client can be configured w/ the following in custom config to prevent it.

proto udp4
pull-filter ignore "ifconfig-ipv6"
pull-filter ignore "route-ipv6"

In fact, on some firmware, in the GUI you have the option of udp, udp4, udp6, tcp, tcp4, and tcp6, rather than just udp/tcp. If the Merlin OpenVPN client is only going to support IPv4 anyway, it might be a good idea to have the firmware map udp/tcp to udp4/tcp4 automatically.

I think the bigger problem is the fact the clients are simply bound to both IPv4 and IPv6, and the latter is still addressable over the WAN while the OpenVPN client is active.

 

[Frank Monroe]

ip6tables -I FORWARD -m mac --mac-source 00:01:02:03:04:05 -j REJECT

I have tested the on my RT-AC5300 and it does solve the problem.

 

[Yota]

Use a VPN that supports IPv6

Just to clarify, currently Asuswrt-Merlin (386.7_2 and 386.8) only supports IPv6 in the OpenVPN server, not IPv6 on the client side yet, which means that even if your VPN provider supports IPv6, your router won't know there's any available IPv6.

 

[Kingp1n]

Ideally, if the OpenVPN client supported IPv6, you could bind those same IPv4 clients to the VPN w/ the VPN Director and solve the problem. But even so, the solution is actually quite simple, and requires no changes to the OpenVPN client. As I suggested before (and Merlin reiterated), it's a simple matter to create ip6tables rules to block those same IPv6 devices.

ip6tables -I FORWARD -m mac --mac-source 00:01:02:03:04:05 -j REJECT

You could either create a firewall-start script if you want this enforced 24/7, or else an openvpn-event script to add and remove them as the routes come up and down, respectively.

No, I don't have any such script at hand. But if you take the firewall-start approach, it should be pretty easy to do

Would you simply add this rule to the firewall-start script and of course change the mac source to match my devices?

 

[eibgrad]

Would you simply add this rule to the firewall-start script and of course change the mac source to match my devices?

Yes.

 

[SomeWhereOverTheRainBow]

Just to clarify, currently Asuswrt-Merlin (386.7_2 and 386.8) only supports IPv6 in the OpenVPN server, not IPv6 on the client side yet, which means that even if your VPN provider supports IPv6, your router won't know there's any available IPv6.

Yea it doesn't stop the openvpn source from trying to configure the ipv6 traffic. Without specifically placing an exclusion inside the .ovpn file or the .conf file, the vpn source will still configure the connection. Since asuswrt-merlin firmware doesn't set up the necessary rules to route the traffic through the ipv6 tunnel, it just appears as leaked traffic because the vpn source is allowing the ipv6 leak outside the tunnel for client traffic.

 

[Sas]

...

ip6tables -I FORWARD -m mac --mac-source 00:01:02:03:04:05 -j REJECT

OMG this works so well, thanks! Now I just need to figure out how to make it enable itself automatically...