SomeWhereOverTheRainBow
Part of the Furniture
The guys over at broadcomm are on their lunch break. It will have to be whenever they come back...No rush. Take your time whoever is still working on it.
The guys over at broadcomm are on their lunch break. It will have to be whenever they come back...No rush. Take your time whoever is still working on it.
My ISP implemented IPv6 May 2019.And that's the challenge perhaps...
WAN-side is a challenge, as ISP's have multiple methods there...
That being said - not Eric's problem to solve, this needs to be upstream from Asus...
In this case Beta = no support.
I've seen that many ip addresses with an ipad here, it happens when the client is set in private wifi address and the connection is unstable(in/out) usually the battery is running low. However, it clears the addresses after 12 hrs., they have very short leases so it seems it's not a bug.By the way:
View attachment 45433
32x IPv6 addresses already and counting... this is getting entertaining. Really, really IPv6 hungry iPhone.
This one is more satisfied in life:
View attachment 45434
it happens when the client is set in private wifi address and the connection is unstable
Your choice nothing we can do about that, me, i'll continue my journey.The phone is in the same room and private address is disabled. This is ridiculous whatever it is.
Anyway, enough volunteers around, I have the problem solved. The best IPv6 setting in Asuswrt:
View attachment 45435
House full of idevices here, private wifi enabled, problem not seen.I've seen that many ip addresses with an ipad here, it happens when the client is set in private wifi address and the connection is unstable(in/out) usually the battery is running low. However, it clears the addresses after 12 hrs., they have very short leases so it seems it's not a bug.
This seems to happen when an iDevice or even windows that sleeps in and out of their wireless connections. It appears in ipv6 acquiring addresses is not a problem but it doesn't retain the same IP whenever you come in and out specially if it's rapidly in succession. Good thing the leases are short that it claims it back when its time to renew. I can see trouble when you have a server but I've read that people were able to assign static IP's. When there is a problem like this that's when you learn to find out the solution.House full of idevices here, private wifi enabled, problem not seen.
Might ‘sometimes’ get two or three addresses, but very rarely.
This script forces all IP6 traffic through the VPN tunnel... if the VPN tunnel goes down, no IP4 or IP6 traffic will be allowed to get out.To prevent IPv6 leaks you have to kill IPv6 traffic when your IPv4 tunnel is up as well. It doesn't make much sense to me. First you enable IPv6 for unknown reason and then kill it because you want to use IPv4 only tunnel. Keeping IPv6 disabled on the router solves IPv6 leak issues permanently.
The GUI relies on the output of the command:By the way:
View attachment 45433
32x IPv6 addresses already and counting... this is getting entertaining. Really, really IPv6 hungry iPhone.
This one is more satisfied in life:
View attachment 45434
ip -f inet6 neigh show dev br0
echo 16 > /proc/sys/net/ipv6/neigh/default/gc_thresh1
It should be noted that before anyone chooses to take this approach, they should actually review information about "ARP cache sizes and GC thresholds" to determine if this the actual approach they wish to take.The GUI relies on the output of the command:
to populate that client list. By default, Linux won’t cleanup stale entries until the list is over 128 entries.Code:ip -f inet6 neigh show dev br0
If anyone wants to lower this threshold, you can modify it:
where 16 could be any number less than 128, maybe close to double the number of IPv6-capable devices on your LAN.Code:echo 16 > /proc/sys/net/ipv6/neigh/default/gc_thresh1
/proc/sys/net/ipv6/neigh/default/gc_thresh1
/proc/sys/net/ipv6/neigh/default/gc_thresh2
/proc/sys/net/ipv6/neigh/default/gc_thresh3
To prevent IPv6 leaks you have to kill IPv6 traffic when your IPv4 tunnel is up as well. It doesn't make much sense to me. First you enable IPv6 for unknown reason and then kill it because you want to use IPv4 only tunnel. Keeping IPv6 disabled on the router solves IPv6 leak issues permanently.
Get a VPN provider that support IPv4/v6, problem solved..
I tried a couple IPV6 supported VPN providers and they still had DNS leaked during my testing.Get a VPN provider that support IPv4/v6, problem solved..
If you are running the VPN Director VPN clients on the router, then you will have IPv6 leaks, because the clients themselves do not support IPv6. @RMerlin does not have access to an IPv6 ISP and without this it is not practical to do the work necessary to get this to work. As noted elsewhere you can disable IPv6 on the router, or just disable IPv6 on the devices routed through the tunnel(s).I tried a couple IPV6 supported VPN providers and they still had DNS leaked during my testing.
I tried a couple IPV6 supported VPN providers and they still had DNS leaked during my testing.
@Kingp1n As @archiel has correctly posted, those problems can only be due to the specific setup (...that you're currently using).If you are running the VPN Director VPN clients on the router, then you will have IPv6 leaks, because they clients themselves do not support IPv6. @RMerlin does not have access to an IPv6 ISP and without this it is not practical to do the work necessary to get this to work. As noted elsewhere you can disable IPv6 on the router, or just disable IPv6 on the devices routed through the tunnel(s).
If you want to use VPN providers who supports IPv6 then your current options are
connect via the provider's own clients (not the router)
move your VPN routing to a device that does support dual stack VPN routing (I believe it can be done on a pi, have never tried)
on a supported Asus device, run @ZebMcKayhan's Wireguard Manager (WGM)
I use WGM, with dual stack and no leaks, but I also have a slow ISP (for fast links Wireguard will speed limit your whole network, not just the VPN tunnels)
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!