320262a7f0
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> |
||
---|---|---|
.circleci | ||
.github | ||
.keys | ||
admin | ||
devel | ||
fonts/dejavu-fonts-ttf | ||
ipv6 | ||
kernel | ||
lang | ||
libs | ||
multimedia | ||
net | ||
sound | ||
utils | ||
CONTRIBUTING.md | ||
LICENSE | ||
README.md |
README.md
OpenWrt packages feed
Description
This is the OpenWrt "packages"-feed containing community-maintained build scripts, options and patches for applications, modules and libraries used within OpenWrt.
Installation of pre-built packages is handled directly by the opkg utility within your running OpenWrt system or by using the OpenWrt SDK on a build system.
Usage
This repository is intended to be layered on-top of an OpenWrt buildroot. If you do not have an OpenWrt buildroot installed, see the documentation at: OpenWrt Buildroot – Installation on the OpenWrt support site.
This feed is enabled by default. To install all its package definitions, run:
./scripts/feeds update packages
./scripts/feeds install -a -p packages
License
See LICENSE file.
Package Guidelines
See CONTRIBUTING.md file.