it's not clear from your message does the HTTP call go through the VPN or over the internet. If you have the VPN endpoints both as active then all packets in same connection always go over the same tunnel (same endpoint). In aggregate mode the packets go round-robin over both tunnels/endpoints and may cause issues for some applications if latency and throughput for the two links are very dissimilar.
Connection_Interface_Changed should be generated I think if outgoing interface changes due to dynamic routing. It alone anyway doesn't indicate any problem. I'd run tcpdump for the HTTP traffic and see what happens, maybe there's a path MTU issue or something. That could be solved with MSS rewriting.
Great to see you are still in the team !!
All the calls are for “NOT Local” and therefore don’t match VPN traffic and are used for Local Internet Break out. I don’t want to use QoS just for HTTP on a single link in this case.
This issue only happens when we have Active / Active. This O-Mult-Link is a 2x netlink with 1xDynamic and 1 x Static. To form the multilink.
There are instances where all works well until the Connection_Interface_Changed appears and then I need to go A/S
Can you confirm what triggers the entry Connection_Interface_Changed ?
Thanks! I thought the HTTP traffic goes via the VPN, but instead it's NATed with the outbound multi-link. The dynamic netlink could be related, if it's PPPoE or similar then you usually need to do MSS rewrite.
>Can you confirm what triggers the entry Connection_Interface_Changed ?
It should come just with dynamic routing when the route changes in middle of connection. But we have seen these sometimes also without dynamic routing, if you're inspecting the HTTP traffic you could try disabling that. If it still happens in latest 5.8 or newer then it may be best to open a support ticket.