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>
In commit 502779755a, the code was
modified to use the mwan3_push_update helper, but the IPTR was not
defined per the address family being utilized.
Signed-off-by: Tim Nordell <tnordell@airgain.com>
Addition of iptables rules for mwan3 sticky rules is broken, resulting
in non-working sticky rules. The required parameters for the function
'mwan3_set_sticky_iptables' were passed in the wrong order.
Signed-off-by: Anna Tikhomirova <vamp@vampik.ru>
* Update commit message
* Quoting function arguments
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Nft does not directly support ipsets, nft sets must be used instead.
The mwan3 uses ipsets for certain tasks. They can be combinded. So called
an ipset of ipsets. This list type is not available in nft. So that
mwan3 could be ported to nft in the feature, the ipset handling should be
split. So we have for each ipset an iptables rule.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Until now the additional tables listed in gobal 'rt_table_lookup' were
not considered for interfaces.
In order to be able to also use interface-defined routes from tables
other than main, consider also tables listed in 'rt_table_lookup'.
Update version to 2.10.10 as requested by maintainer.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Allow `mwan3 interfaces` to get uptime via an internal function and
thus remove the dependency on rpcd for `mwan3 interface` calls.
Signed-off-by: Aaron Goodman <aaronjg@stanford.edu>
It was somewhat opaque how the variable a is questioned. To show this
better the variable is now a string and not a boolean. So you can see
directly what should happen. With a boolean you always have to think
about what it means when 0 or 1 is used.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Replace locks on /var/run/mwan3.lock with locks via procd.
This fixes a deadlock issue where mwan3 stop would have a procd
lock, but a hotplug script would have the /var/run/mwan3.lock
Locking can be removed from mwan3rtmon since:
1) procd will have sent the KILL signal to the process during
shutdown, so it will not add routes to already removed interfaces on
mwan3 shutdown and
2) mwan3rtmon checks if an interface is active based on the
mwan3_iface_in_<IFACE> entry in iptables, and the hotplug script
always adds this before creating the route table and removes it
before deleting the route table
Fixes github issue #13704
(https://github.com/openwrt/packages/issues/13704)
Rather than using a special mwan3 user to manage mwan3track's tracking
packets, this commit implements a small helper library to bind to
device and to set a fwmark so that the tracking packets can be routed
out of the correct interface.
This provides a consistent method for binding to a device rather than
relying on various packages potentially buggy implementations. For
example: #8139 and #12836
This helper issue also allows for more tracking methods to be added
even if they do not have a command line option to bind to device,
such as iperf3 (eg #13050).
Signed-off-by: Aaron Goodman <aaronjg@stanford.edu>
start all mwan3mon and mwan3track instances on mwan3 start
if an interface is down when mwan3track starts, it waits
for a signal from the hotplug script to start
procd can then handle stopping all of the scripts when mwan3
is halted
Signed-off-by: Aaron Goodman <aaronjg@stanford.edu>
correctly terminate interface status checks with new lines so that
interface status does not get confused when one interface is a prefix
of another interface.
Signed-off-by: Aaron Goodman <aaronjg@stanford.edu>
handle creation of routing tables in mwan3rtmon to avoid race
conditions and potentially missing routes
handle ipv6 routes that have expiry
update directly connected ipset when routes are added or deleted
add fall through rules so that the default routing table is not
used if no rule in the interface-specific routing table matches
add option to comply with mwan3 source based routing
get default route parameters from main routing table
Signed-off-by: Aaron Goodman <aaronjg@stanford.edu>
improve startup and runtime performance by
1) moving common startup procedures out of hotplug script when called
from mwan3 start
2) reducing calls to iptables to check status of rules
3) consolidating iptables updates and updating with iptables-restore
4) do not wait for kill if nothing was killed
5) running interface hotplug scripts in parallel
6) eliminate operations in hotplug script that check status on every
single interface unnecessarily
7) consolidate how mwan3track makes hotplug calls
8) do not restart mwan3track on connected events
This is a significant refactor, but should not result in any breaking
changes or require users to update their configurations.
version bump to 2.9.0
Signed-off-by: Aaron Goodman <aaronjg@stanford.edu>
use only committed uci changes for updating routing table
use functions.sh functions rather than uci command line tool
to find interfaces for routing table.
consolidate rtmon_ipv4 and rtmon_ipv6 functions into a single function
Signed-off-by: Aaron Goodman <aaronjg@stanford.edu>
This reverts commit cde2a77ed3.
Applying this change has shown that it is even quicker to provoke the
race condtition on simultan mwan3 commands execution.
By reversing the change we have the same behaviour as before.
But the race condition on mwan3 execute at the same time still exists.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
If the uci option family is not set in the interface section, then there
is no default value set as in the `config_load / config_get` API.
The problem here is that if the family is not set, the default value ipv4
is normaly assumed. But the comparison fails here because the value is empty
and therefore the dedicated routing table for this interface is not compared
with the other routes from the main table and so not updated.
To fix this set the default value for this config option which is`false`
for enabled and `ipv4` for family.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
This fixes routing handling. Introduced with the last version update.
The following message disappears on the shell
when mwan3 is called with 'mwna3 restart`.
`Error: Invalid gateway address.`
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
[aaronjg@stanford.edu: fully unset variable and handle ipv4 as well]
Signed-off-by: Aaron Goodman <aaronjg@stanford.edu>
Tim Nordell