How is it possible that the traffic count on WAN6 is higher than on WAN?
I am running LEDE and I am using 6in4 with HE-tunnel for IPv6. If I look at the traffic count, I can see that the traffic for WAN6 is higher than for WAN. But since every 6in4 packet has to go through the WAN interface as well, how can it be that traffic on WAN6 is higher than on WAN? Or is that traffic somehow excluded from WAN statistics? And if yes, how and why would that be?
Also: I am still seeing quite some traffic on WAN, even though the 6in4 tunnel is everything the device does, no ordinary IPv4 traffic is being routed through the device as there's another gateway in my network for that.
6in4 uses kernel module sit and specific protocol IP-protocol-41, which is not TCP/UDP/ICMP/etc., so it's either not counted or intercepted before it's counted.
I believe you refer to Network-Interfaces counters in Luci. Has WAN interface been restarted? That could be a reason to reset the counters. Do they have the same uptime?
You should see at least the same amount of traffic as the WAN6 goes through WAN, however you will have some control packets in WAN interface.
Yep, the counters in Luci. Uptime is the same, no disconnects or resets.
Yes, I know there's some overhead, so I'd expect the WAN interface to have more traffic, not less (ratio is about 1:10, i.e. 10 GB on WAN6, and only 1 GB on WAN). And I am talking about combined TX/RX.
I can only imagine that the traffic counter is so 'clever' that it doesn't count WAN6 on WAN. But in that case the traffic on WAN appears to be a little high, I feel.
The Interface you see should be an alias, so WAN6 shows the stats of the true interface. In most cases, that eth0.2/WAN/VLAN 2 on devices with switches installed.
That behavior should be easily changed by changing it to a virtual interface (for example); but I don't recommend it (OpenWrt is kinda doing that by aliasing it - see the related code and Wkiks).
I didn't edit the WAN6 interface. I just set it to use 6in4 (instead of e.g. DHCPv6 or 6to4) as connection method. But yeah, must be some filter there. Maybe it has to do with that I am using only the WAN interface to connect to the network. So traffic flows as follows:
In OpenWrt 18.06.2, there is a default WAN6. For HE Tunnelbroker, you should not edit WAN6 in any manner whatsoever. Per HE's Tunnelbroker site, you create an Interface called henet.
Did you follow the instructions at the Tunnelbroker site?
I don't experience the issue you're describing on versions 17 and higher:
@lleachii, if the ISP doesn't provide IPv6, there's nothing wrong in utilizing unused interface wan6.
It helps to simplify firewall configuration and works the same way, no matter how you name the interface.
You see, wan and wan6 have different ifname so the aliasing is disabled.
Hm, I still have difficulties wrapping this up in my head. Anyway, I created an additional device, now I do get the same traffic on WAN and WAN6, HENET is slightly lower. I even deleted WAN6 and it's still working (which it should from my understanding). So it really seems that for some reason WAN6 is not counted towards WAN, though I don't understand at what level that happens. Kernel?
Originally I used the setup description on the OpenWrt-website which suggests to use the WAN6 interface for 6in4. But now I went as per the description by HE. Unfortunately, this setup seems to drastically impact the network throughput (from 100 MBit/s I only get 50 MBit/s, but I should check with different servers first). On the other hand, traffic now seems to get counted 'correctly'. Well, speed is more important for me in the end. Seems like this was related only to the speedtest server.
But IF kernel filters WAN6-6in4, I still don't get how WAN could still show several GB (well, more or less 10% of WAN6) of traffic. That seems a bit too big for overhead, doesn't it?
I don't see how changing the name used in uci and luci from wan6 to henet, or the reverse, should make any difference as long as you update the firewall zones and other config options which contains the interface names.
Me neither. But that's how it appears. Firewall settings just reference zones, not interfaces. Since 'henet' is part of WAN-zone, no changes to firewall settings were necessary. I can only imaging some internal tagging. I observed the same behavior when I was running OpenWrt 18.
