I'm seeing a similar issue. I have a hAP ac lite as my main gateway, and then run a bunch of wireguard tunnels on a CHR on the same LAN which use the hAP as the gateway...
All wan/pppoe connections are marked respectively...
When I experience a wan failover event, I change default gateway, and then remove all firewall connections matching the "failed" wan.. It mostly works fine...
However, one of the wireguard tunnels, which has roughly 1.5Mb of concurrent traffic flowing through it at all times, does not want to switch over, unless I manually block/reject with a filter rule ? Why is this? For some reason this tunnel won't switch back to the primary gateway when it returns and I wipe the failover connections:
[admin@hAP] > put [/ip/firewall/connection/find where connection-mark=pppoe2_lans]
*5d5e3
[admin@hAP] > /ip/firewall/connection/remove [find where connection-mark=pppoe2_lans]
[admin@hAP] > put [/ip/firewall/connection/find where connection-mark=pppoe2_lans]
*5d5e3
[admin@hAP] > /ip/firewall/connection/remove [find where connection-mark=pppoe2_lans
[admin@hAP] > put [/ip/firewall/connection/find where connection-mark=pppoe2_lans]
*5d5e3
[admin@hAP] >
One strange thing I did notice is the following:
[admin@hAP] > put [/ip/firewall/connection/get [find where connection-mark="pppoe2_lans"]]
invalid internal item number
[admin@hAP] > put [/ip/firewall/connection/get [find where connection-mark="pppoe2_lans"]]
invalid internal item number
no such item (4)
[admin@hAP] > put [/ip/firewall/connection/get [find where connection-mark="pppoe2_lans"]]
.id=*5d5e3;assured=true;confirmed=true;connection-mark=pppoe2_lans;dst-address=xxx.36.7.80:11210;dstnat=true;dying=false;expected=false;fasttrack=false;hw-offl
oad=false;orig-bytes=78208360;orig-fasttrack-bytes=0;orig-fasttrack-packets=0;orig-packets=199860;orig-rate=1487424;protocol=udp;repl-bytes=964380;repl-fasttra
ck-bytes=0;repl-fasttrack-packets=0;repl-packets=6125;repl-rate=20832;reply-dst-address=xxx.183.102.251:11220;reply-src-address=192.168.100.1:11210;seen-reply=
true;src-address=xxx.183.102.251:11220;srcnat=false;timeout=00:03:00
This sort of intermittency and unreliability can be really frustrating .. It would be great if every connection is removed as commanded ..
Running Ros v7.1rc6, not sure if this happens with other versions
Edit: Ok so it turns out the persistent pppoe2_lans connection was caused by an incoming connection from the remote host being marked. However I'm still having problems closing some other connections and the script terminates