Advanced/Policy Routing - where does it go?

Installing and Using OpenWrt Network and Wireless Configuration
1

Hi -

I have a setup on one lede router comprising an uplink to the rest of my network, and then two wireguard interfaces for two wireless clients.

I route via the addition of two routing tables for each of the interfaces, and then iptables marking packets from the clients.

I could put this config - minus the iptables rules - into config/network - but that doesn't seem to be a particularly elegant place to put it - given as it relies on custom iptables rules in firewall.user.

Is there a better way? Is mwan a solution here ? (I assumed it was more about load balancing).

2

Policy routes would begin with ip rule add, the rule would then specify the policy (via IP or interface) and the respective IP table.

I tend to place my policies in Startup, it also called /etc/rc.local if accessing it via the CLI.

For clarity's sake...what about your setup do you think may be Load Balancing?

3

Policy routes would begin with ip rule add, the rule would then specify the policy (via IP or interface) and the respective IP table.

So to be clear - this is what I have already. However this isn't the 'openwrt way' in that it removes some of the config outside the control of the networking subsystem (which has an impact when an interface goes up/down). It appears there is a way of specifying policy rules that operate via fwmark via the config/network file: https://openwrt.org/docs/guide-user/network/ip_rules

and: https://openwrt.org/docs/guide-user/network/routes_configuration

However, there doesn't appear to be any way of tying specific iptables rules (in this case the ones that mark traffic so that they can be handled by a particular table) against a routing rule.

For clarity’s sake…what about your setup do you think may be Load Balancing

Absolutely nothing, that was a comment on the mwan package which most people seem to use in the case where they are attempting to load balance across different wan uplinks - however it seems that in principle it could also be use to differentially route traffic to different wan links based on things other than traffic loading.

4

@cbz...Interesting link...

I need to test by attempting to convert some of my policy routing rules into the UCI...at this time, I'm using the startup option.

I don't think the rules "operate via fwmark." I simply think 'mark' is one option for identification in the example.

5

OK, I have tested. I have successfully added all my routes and rules in the "OpenWRT way!" Here is a rule I have for a VLAN that carries an AMPR.org subnet:

config rule
option src '44.xxx.xxx.0/24'
option priority '47'
option lookup '44'

This adds an IP rule in position number 47 - stating that any IP from the SRC IP should use route table 44 for its lookup.

I was also able to place my route rules into the UCI. Thanks! Hope this helps you too.

6

So I have something similarish - because in my case I just want to drop the single default route in the wireguard table:

config route 'wg0_route'
        option interface 'wg0'
        option target '0.0.0.0'
        option netmask '0.0.0.0'
        option table 'wireguard0'

Which drops the rule:

default dev wg0  proto static  scope link

I don’t think the rules “operate via fwmark.” I simply think ‘mark’ is one option for identification in the example.

Yes, that wasn't meant in the exclusive sense. The mechanism clearly also allows the dropping of rules that would be triggered by fwmarks. Currently in the mangle table the PREROUTING chain is classifying a bunch of traffic with a mark destined for this table - there's just seems to be no mechanism for tying the iptables rules to the policy rules that they are doing work for.

7

If I understand correctly, I think a simpler method would be to disable making routes for the "Allowed IPs" in Wireguard, especially if the allowed subnet is 0.0.0.0/0.

From there, make your own routes and rules regarding what traffic will use the Wireguard interface.

For example, you can make a rule that 128 of your IPs use the Wireguard by specifying in CIDR a 192.168.1.128/25. If your set you DHCP correctly, then your dynamically assigned LAN devices will use it automatically!

Simply allow forwarding from the SRC Zone (i.e. lan) to the Wireguard zone, and don't worry, your devices won't use the route until you specify they should via a rule that applies to them.

8

So to be clear - I have routing to and from wireguard working fine with the types of traffic I want, using a combination of startup commands with 'ip rule/ip route' commands plus some iptables routes which work to classify traffic and mark it appropriately. Some traffic is non-tunneled correctly, other traffic is tunneled correctly

Everything is working as intended. I just want to see if I can put the config into a purely openwrt/lede form. So there are two things I'm trying to do, first express the 'ip rule/route' commands in a purely openwrt form, secondly express the traffic marking in a purely openwrt form rather than as a set of custom rules (a few iptables commands to mark traffic appropriately).

So this won't work - though I've read netifd and it seems it should parse and should send it to the netlink interface at least:

config rule 
    option mark '0x64'
    option in   'br-lan'
    option lookup 'wireguard0'

Related to the second, there's no easy hook for traffic classification that I can see. The firewall can match against marks but can't be used to generate them.

9

You can specify rules in /etc/config/firewall which set traffic marks, see https://wiki.openwrt.org/doc/uci/firewall in the "rules" section.

A classification rule would look like:

config rule
  option src wan
  option src_ip 1.2.3.0/24
  option proto all
  option target MARK
  option set_mark 123

As for ip rules in /etc/config/network; the "option in" refers to a logical name, so it needs to refer to lan not br-lan.

1 Like
10

Silly question, would it also be possible to set DSCPs instead of traffic marks with the same/similar interface? That would make it much simpler to deal with the typical combination of DSCP-aware AQM setups (like SQM and QOS?) and non-DSCP-aware software on the internal endhosts?
Some of the setups in sqm-scripts internally work with firewall marks and hence should be able to use this mechanism, but cake does not (due to its nice set of features, we do recommend cake for sqm-scripts users, but so far just punted on the problem how to get the desired marks on the packets; and this mechanism would at least allow this for egress, by setting up rules for lan, I guess).

11

This is not yet (directly at least) supported, but I'll look into adding -j DSCP --set-dscp ... handling later. In the meanwhile you can achieve this using the following notation:

config rule
        option name 'Apply DSCP mark'
        option src 'wan'
        option dest 'lan'
        option proto 'all'
        option extra '-j DSCP --set-dscp 1'
3 Likes
12

Thank you very much. I will take this to a test drive and once I get this to work I will try to add instructions for this in the wiki.

1 Like