How to work with VPN traffic, which is defined as unknown?

Hello everyone. As part of the QoS setup, I noticed that incoming traffic for VPN networks is perceived by QoS as unknown and cannot be analyzed properly by it.

Both p2p and rdp traffic are marked with unknown traffic. This has serious problems for me because these types of traffic have different priorities and I want to separate them.

If perform similar actions without being on a VPN network, then the traffic is correctly distributed among all the allocated classes.

I suppose this has something to do with the fact that QoS does not work on tun0, tun1 interfaces. However, how can I prioritize such traffic?

Of course, I have a separate rule for the vpn class for incoming traffic, but for the VPN network it does not work and traffic is directed either to the default class or to the one where there is a level 7 rule - unknown.

Is your OpenVPN server <> server or roadwarrior <> server. If it is roadwarrior <> server, the QoS rule looks wrong as the roadwarrior will use high ports.

Hello, Nick. In this case, the question concerns the “roadwarrior <> server”.

  1. I see that the client connects from a real address to random ports 61132, 51306, 54198, etc.
    It turns out that I have to add separate rules with
    Destination port: 1194 for outgoing connections and source port: 1194 for incoming connections, to account for this traffic?

  2. Ports 1195-1196 are used by the OpenVPN network server. These rules, I can leave the rules unchanged, right?

Yes you are on the right lines. depending on your connection I would not bother with inbound QoS. e.g my line is 800/80. Inbound I can handle just about anything. It is more the outbound I would be concerned about…

I think you have 1. the wrong way round. IPFire will listen on UDP:1194 and reply from the same, so you want from Any to UDP:1194 for inbound and to Any from UDP:1194 for outbound.

  1. should be OK but I don’t have the set up to test. A quick tcpdump will show it.

Thank you for your answers. I will try

Nick, I’ve followed your recommendations. Thanks to this, it was possible to divide into 2 separate classes: external traffic (srv-RW) and external traffic (srv-srv) - only the MX server communicates there. Thank you.

However, the main question remains - how to work with traffic that travels through other interfaces? tun0 and tun1, which I mentioned earlier

It is not present on the red0 and imq0 interfaces, which is logical because this is internal traffic.

[root@gw ~]# tcpdump -i red0 -c 10 host 192.168.7.182
tcpdump: verbose output suppressed, use -v[v]… for full protocol decode
listening on red0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C
0 packets captured
13 packets received by filter
0 packets dropped by kernel

[root@gw ~]# tcpdump -i imq0 -c 10 host 192.168.7.182
tcpdump: verbose output suppressed, use -v[v]… for full protocol decode
listening on imq0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C
0 packets captured
21 packets received by filter
0 packets dropped by kernel

[root@gw ~]# tcpdump -i tun1 -c 10 host 192.168.7.182
tcpdump: verbose output suppressed, use -v[v]… for full protocol decode
listening on tun1, link-type RAW (Raw IP), snapshot length 262144 bytes
17:23:54.927871 IP 192.168.7.182.56305 > 192.168.8.18.ms-wbt-server: UDP, length 12
17:23:54.966679 IP 192.168.8.18.ms-wbt-server > 192.168.7.182.56305: UDP, length 76
17:23:55.053044 IP 192.168.7.182.56305 > 192.168.8.18.ms-wbt-server: UDP, length 12
17:23:55.060687 IP 192.168.8.18.ms-wbt-server > 192.168.7.182.56305: UDP, length 74
17:23:55.115709 IP 192.168.7.182.56305 > 192.168.8.18.ms-wbt-server: UDP, length 12
17:23:55.185521 IP 192.168.8.18.ms-wbt-server > 192.168.7.182.56305: UDP, length 75
17:23:55.242169 IP 192.168.8.6.http > 192.168.7.182.60677: Flags [S.], seq 2062167230, ack 3117272492, win 64240, options [mss 1155,nop,nop,sackOK,nop,wscale 7], length 0
17:23:55.242296 IP 192.168.8.6.http > 192.168.7.182.60675: Flags [S.], seq 3313654494, ack 1872910964, win 64240, options [mss 1155,nop,nop,sackOK,nop,wscale 7], length 0
17:23:55.243736 IP 192.168.7.182.60677 > 192.168.8.6.http: Flags [.], ack 1, win 514, options [nop,nop,sack 1 {0:1}], length 0
17:23:55.246067 IP 192.168.7.182.56305 > 192.168.8.18.ms-wbt-server: UDP, length 12
10 packets captured
21 packets received by filter
0 packets dropped by kernel

I tried to solve this by limiting the speed of the interfaces. The allocation for red0 is 48%, for tun0 and tun1 is 24%. However, it didn’t work

The traffic for QoS only became “unknown” and went to the default class, where the limit was reached and I observed packet dropping for a rdp connection from inside the network.

This is also true for the VPN RoadWarrior network - there was a drop of VPN packets with messages like:

RoadWarrior/x.x.x.x:2691 Package Authentication/Decryption error: Invalid package ID (possibly a repeat): [ #46660 ] – see the entry on the manual page for more information about … no-analyze and analyze --windows or disable this warning with --mute-repeat-warnings.

I’m sorting this out in another topic: Configure a class for RDP session connection - #8 by siptix

And I still don’t see a way out of this situation.

I don’t know your answer at all, I just spotted a config error.

Conceptually I have a problem with QoS in a VPN. It is possible to prioritise the VPN itself as you have done, but I am not sure how you can prioritise traffic within a VPN. It can’t use the same bandwidth configs as the tunnel as it would compete for bandwidth, which is no use. If it has a separate config what maximum bandwidth do you set for tun+. It must always be less than the outer VPN, but if QoS limits the outer VPN, then you must limit the inner VPN bandwidth or you’ll ruin your inner VPN QoS.

I am afraid I have never tried it as I can’t get my head round it.