People might read documentation similar to https://openwrt.org/docs/guide-user/network/wan/simple_wan_failover and set up fail-over scenarios based purely on route metrics, without any policy-based routing.
I also made this mistake by configuring my USB LTE modem for the second WAN with metric = 90. The primary WAN is a PPPoE-based fiber connection with metric = 0.
This is a mistake because of the following consideration.
Suppose that LTE connects first, and the fiber connection comes up second. Devices in LAN could establish some connections to servers on the Internet in the meanwhile (i.e., while the LTE connection was the only working one). But then, the default route changes.
Servers on the Internet still send us packets over wwan0:
12:48:21.734832 IP 142.251.10.94.443 > 100.66.218.127.60968: Flags [P.], seq 0:73, ack 1, win 1041, options [nop,nop,TS val 523506531 ecr 3258400847], length 73
Yet, the replies go out via pppoe-wan, using the IP address of wwan0:
12:48:21.734915 IP 100.66.218.127.60968 > 142.251.10.94.443: Flags [R], seq 3538110809, win 0, length 0
This constitutes IP spoofing and, for some ISPs, even a single spoofed packet is a ground for contract termination.
Please make sure that OpenWrt, when NAT is enabled on a WAN connection, never sends any packets out with the "wrong" source address, unless a specific range is excluded from NAT. Even when a user follows such misguided guides.
EDIT: let me make this more specific.
The default firewall should examine each outgoing packet at the last possible point before sending it out, when all addresses in the packet header are final, regardless of whether it has undergone a NAT or not.
As a general rule, if masquerading is enabled on the interface, and the source address of the packet does not match any of the addresses assigned to the outgoing logical interface, then drop the packet. Even better, in addition to the safety check mentioned in the previous sentence (not instead!), make sure that the packet is not routed to the wrong interface in the first place.
Of course, facilities should be provided when creating a NAT rule to override this check. For example, it would be needed if a certain source or destination prefix, or their combination, is excluded from NAT.
Note that there is already a firewall rule with the purpose to prevent NAT leakage:
table inet fw4 {
chain accept_to_wan {
meta nfproto ipv4 oifname { "wan", "wwan0", "pppoe-wan" } ct state invalid counter packets 97 bytes 3880 drop comment "!fw4: Prevent NAT leakage"
oifname { "wan", "wwan0", "pppoe-wan" } counter packets 1049 bytes 214309 accept comment "!fw4: accept wan IPv4/IPv6 traffic"
}
}
But it only deals with leakage from connections established before the router has rebooted, not leakage from changed routing due to a lower-metric interface going up—and that's the subject of this request.
