Hello please see thread https://community.ipfire.org/t/ipsec-tunnel-crippled-by-qos/5619 It seems that QoS is halving my throughput using IPSec. Only turning off QoS seems to fix. I have correctly classified the VPN traffic, even put the iperf traffic into the VPN category so that all traffic is the one category. I ensure that the maximum bandwidth is at my maximum bandwidth, and yet it absolutely smashes my ipsec tunnel. I am unsure if it is related to the other bug that has been closed as not a bug, but for me this seems to be a bug, the only work around is to totally turn off QoS. My fireinfo https://fireinfo.ipfire.org/profile/2e62a4891269f0e9d5b070ecf08ad99706dd153a
It looks like we mark the internal IPsec traffic and send it through the subclasses which should not happen. Instead we should skip processing all of the marking rules inbound and outbound for any packet that is received from or being sent to an IPsec network. Ian, can you confirm that traffic is halved in both inbound and outbound direction or just one?
(In reply to Michael Tremer from comment #1) > Ian, can you confirm that traffic is halved in both inbound and outbound > direction or just one? My outbound link is only ~12mbits and I am achieving ~11mbits out, so definitely not halved going out, however is it still throttled? I fear my uplink isn't fast enough to know for sure.
Hi, Is there a work around for this issue until it is fixed? Some IPTables commands or something? Thanks
Hi there, Just checking if this is being worked on as there hasn't been any further comments or updates since I was last asked to provide information. Not trying to rush you, just want to know if it is being worked on.
Im run into the same problems that is the reason why michael has assignend this to me. The problem is the kernel internal handling of IPSec traffic that runs two times through the IPTables stack. In upstream direction there is a rule that prevent from double counting but in downstream there is a bug. At the moment i have to finish some other things first...