This introduces a new concept of "unknown_wan" to mwan3. The action for
this can be configured in the globals section the default of which is
'none'. This can be set to 'none', 'default', 'unreachable' or 'blacklist'
switching out the matching ip rule for this match. This assignment for
a connection is temporary and is re-resolved for each additional
original direction packet through the firewall allowing the unknown WAN
to start resolving once the ifup has finished for the given interface.
An example configuration:
config globals 'globals'
option unknown_wan_action 'unreachable'
Prior to this commit, mwan3 had multiple hit spots for packets in the
following order:
1. Packets are checked to see if they originate from known WAN interfaces
2. Packets are checked to see if they destined for ipsets defined
3. Packets are checked against default WAN policies
The WAN list is maintained via hotplug 'ifup'/'ifdown' events and the local
route ipset list is maintained via monitoring the routing table. This
means that while a WAN interface is brought up, the list for 2 is
updated before the list for 1, since an interface is fully brought up
before the ifup event is fired off. Additionally, we want to make sure we
don't apply a WAN policy for incoming packets from a WAN interface that
is in the process of being brought up.
We can identify packets that are presumably coming from a WAN interface
we don't recognize yet by eliminating all packets that the source comes
from networks we don't know about in the ipsets that mwan3 manages. We
have to be careful here to only match the original direction of the
packet flow (e.g. for instance with ICMP, the ping request is in the
ORIGINAL direction, and the response is in the REPLY direction) or else
we might match something we didn't intend to.
By modifying the rule set to the following:
1. Packets are checked to see if they are in a REPLY direction of flow
2. Packets are checked to see if they originate from known WAN interfaces
3. Packets are checked to see if they not sourced from ipsets defined
4. Packets are checked to see if they destined for ipsets defined
5. Packets are checked against default WAN policies
If a packet is in the REPLY direction of flow, we definitely don't want
to do any routing table assignments - we only want to do this for the
original direction of traffic flow. This reduces the amount of rules
parsed within mwan3.
If a packet is not sourced from a defined ipset, this should match any
packet originating from a "default route" upstream. We do this post the
known WAN interface check since we don't know what mask to apply to this
packet at this time until the 'ifup' has completed. It's also setup to
reevaluate this decision by clearing this specific mark when a new
packet comes in in the REPLY direction of flow before any subsequent
evaluations. This allows additional packets for the same connection to
eventually be assigned the appropriate mask once the 'ifup' has
finished.
One easy way to test this out before and after this change is to:
- Bring down wan (e.g. ifdown wan)
- Manually bring up WAN
- This mitigates the firewall rules being added for 1 above, but 2
is still added since this is monitoring the routing interface
- Ping the device from a non-local subnet via the WAN interface; leave
running
- Observe mark set to ICMP session via conntrack
- Bring up wan (e.g. ifup wan)
- Observe mark set to ICMP session from above
Signed-off-by: Tim Nordell <tnordell@airgain.com>
320262a7f0