Policy Based Routing Issue After Installing nodogsplash or opennds

Installing and Using OpenWrt Network and Wireless Configuration
1

Hello everyone,

I'm encountering an issue with Policy Based Routing (PBR) on OpenWRT after installing either nodogsplash or opennds.

Issue Description:

  • PBR works as expected when it's the only package installed.
  • After installing nodogsplash or opennds, PBR stops working.

Current Custom User File Includes Configuration:

  • My PBR script is as follows:
#!/bin/sh

TARGET_SET='pbr_wan_4_dst_ip_user'
TARGET_IPSET='pbr_wan_4_dst_net_user'
TARGET_TABLE='inet fw4'
TARGET_URL="http://www.ipdeny.com/ipblocks/data/countries/vn.zone"
TARGET_DL_FILE="/var/pbr_tmp_vn_ip_ranges"
TARGET_NFT_FILE="/var/pbr_tmp_vn_ip_ranges.nft"
[ -z "$nft" ] && nft="$(command -v nft)"
_ret=1

if [ ! -s "$TARGET_DL_FILE" ]; then
    uclient-fetch --no-check-certificate -qO- "$TARGET_URL" 2>/dev/null > "$TARGET_DL_FILE"
fi

if [ -s "$TARGET_DL_FILE" ]; then
    if ipset -q list "$TARGET_IPSET" >/dev/null 2>&1; then
        if awk -v ipset="$TARGET_IPSET" '{print "add " ipset " " $1}' "$TARGET_DL_FILE" | ipset restore -!; then
            _ret=0
        fi
    elif [ -n "$nft" ] && [ -x "$nft" ] && "$nft" list set "$TARGET_TABLE" "$TARGET_SET" >/dev/null 2>&1; then
        printf "add element %s %s { " "$TARGET_TABLE" "$TARGET_SET" > "$TARGET_NFT_FILE"
        awk '{printf $1 ", "}' "$TARGET_DL_FILE" >> "$TARGET_NFT_FILE"
        printf " } " >> "$TARGET_NFT_FILE"
        if "$nft" -f "$TARGET_NFT_FILE"; then
            rm -f "$TARGET_NFT_FILE"
            _ret=0
        fi
    fi
fi

return $_ret

Questions:

  • Has anyone experienced similar issues when installing nodogsplash or opennds?
  • Are there specific configuration adjustments needed to make these packages work without disrupting PBR?

Any help or insights would be greatly appreciated!

Thank you!

2

Can you run

nft list ruleset

Without and with captive portal then draw diff from two files?

3

OK.I ready upload 2 file with and without nodogsplash .Link view: VIETBACSEUCURITY/file (github.com)

4

seems like a screengrab that does not diff?

5

with nodogsplash we can see the warning

 Warning: table ip mangle is managed by iptables-nft, do not touch!
table ip mangle {
        chain PREROUTING {
                type filter hook prerouting priority mangle; policy accept;
                iifname "br-lan" counter packets 48681 bytes 26051078 jump ndsOU                                                                                        T
                iifname "br-lan" counter packets 48681 bytes 26051078 jump ndsBL                                                                                        K
                iifname "br-lan" counter packets 48680 bytes 26051026 jump ndsTR                                                                                        U
        }

        chain POSTROUTING {
                type filter hook postrouting priority mangle; policy accept;
                oifname "br-lan" counter packets 66875 bytes 123258859 jump ndsI                                                                                        NC
        }

        chain ndsTRU {
                xt match "mac" counter packets 0 bytes 0 xt target "MARK"
                xt match "mac" counter packets 0 bytes 0 xt target "MARK"
                xt match "mac" counter packets 41913 bytes 24972961 xt target "M                                                                                        ARK"
        }

        chain ndsBLK {
        }

        chain ndsALW {
        }
6

Ok now you are starting to make your point.
xt match mac -> kmod-nft-fib
xt target MARK -> kmod-nft-core

Dictionary:
https://wiki.nftables.org/wiki-nftables/index.php/Supported_features_compared_to_xtables
Run

nft list ruleset | grep "xt "

Then add missing nftables kmods to get rid to offloading to old engine.

7

Yes.
NodogSplash is effectively no longer maintained, depends upon iptables, clashes with PBR and FW4, and it is very unlikely that anyone is going to migrate it to nftables.

However, openNDS is fully, 100%, migrated to nftables. It has a higher priority than FW4 (it must do as it a dynamic, border network demarcation service, hence the letters NDS). It is aware of and cooperates with the static FW4 firewall.

Once the openNDS dynamic firewall has allowed client traffic in/out the flow is passed on to the FW4 "firewall" ruleset for ongoing processing.
But here the issue with PBR arises as it attempts to mark packets that are already marked by openNDS using the same mask.

This is easy to fix when using openNDS and is best done in the PBR config.

I would suggest you remove NoDogSplash and all iptables packages and kmods unless you need them for something else, then install openNDS. Once you have it working, we can do the fix for PBR. (The default mode of openNDS is a "click to continue" splash page, very similar to the NoDogSplash default).

3 Likes
8

openNDS the same bug ,PBR no working affter install.

9

You need to patch one of services to use mark-s even further up the mark bitmasks, i.e patch the source.

10

No, it is a config option in PBR.

11

It is not a bug. You need to configure PBR to fix the problem.
I will post what you have to do in a moment.....

12

@VIETBACSEUCURITY @brada4

This is what is wrong:
openNDS uses:

  1. 0x30000 for authenticated allowed packets

  2. 0x30001 for authenticated blocked packets

  3. 0x20000 for trusted packets

  4. 0x10000 used internally

BUT, PBR sets:
service fw_mask default as ff0000 (yup, it's hex)

This means if some other package uses an fw_mark of 0x030001, then once masked, PBR will see it as 0x30000

The PBR config to work correctly;
In PBR's advanced configuration under Luci :
Change the PBR settings as follows:

wan table fw_mark 000100
and
service fw mask 00ff00

Then restart everything, best to reboot.
Should all work after this.

2 Likes
13

Thanks you very much!All work like charm.now Nodogsplash work with PBR :grin: