In the previous test version of the new connections tab, I encountered several fundamental issues. One of them: In conntrack (wich is what im using for getting connection information), both directions of a connection are included, and in certain situations, I mistakenly swapped the source and destination IPs and ports. This should work better in the current version.
Additionally, the connection values (Bytes, Packets, AVG PPS, etc.) previously only considered incoming traffic values. To better differentiate and represent these values, they are now displayed separately for both incoming and outgoing traffic.
Interpretation of Connection Directions:
The direction of connections is now interpreted consistently, regardless of whether they are LAN-to-WAN, WAN-to-LAN, or local connections:
- The first direction recorded in
conntrack is always considered the "original" direction.
- "Source" in the UI always corresponds to the first source IP/Port in the
conntrack entry.
- "Destination" in the UI always corresponds to the first destination IP/Port in the
conntrack entry.
- "Out" (Outgoing) refers to data flowing from the source to the destination.
- "In" (Incoming) refers to data flowing from the destination to the source.
After the installation please clear your browser cache and restart the browser...
Please install the new version of the connections tab and try again. Also for testing DSCP markings please disable Wash DSCP Egress and Wash DSCP Ingress.
@NeMe_FuUuRyyyyY Be aware, your last screenshot may show your public IP address.
@grrr2
Updating to the newest connections.js should hopefully resolve this issue
Do you have a network switch? These often assign some CS6 or CS7 DSCPs out of the box. It’s possible that one of these might have sneaked into the conntrack.
If you're using CAKE, it simply uses the CAKE wash function without additional firewall washing rules. It’s possible that some LAN device might be assigning DSCPs, or maybe even your hypervisor. Could you perhaps use tcpdump to check where the packets marked with CS6 are coming from?
Originally, qosmate also used additional firewall washing rules with CAKE to remove DSCP markings before and after the nftables rules. However, I have discarded this functionality (at least when using CAKE) to allow DSCPs to be assigned directly on LAN devices and have those markings written into conntrack. I wanted to avoid offering a general wash function alongside a specific one just for CAKE, as this might have been confusing for many users.
However, if it becomes necessary, I can reconsider and come up with a solution.
@pesa1234
Technically, you probably still only have a single physical WAN port. You should apply qosmate to this port. This should cover overall traffic shaping, including VPN traffic. Maybe I'm wrong here but packets sent through your VPN tunnel may not be as easy to mark with DSCPs, as the tunnel appears as a single connection and is encrypted. This means that CAKE or HFSC cannot automatically look inside to read the DSCP values.
@Lynx has a lot of knowledge on this topic and has already created several discussions about it. If you want to learn more, just use the search function or check out this link: