Home / server / Questions / 809302
Accepted
Kai Giebeler
Asked: 2016-10-16 19:24:33 +0800 CST

nftable rules get invalidated on reconnect (VDSL, ppp0)

  • 772

I'm rebuilding my router using nftables on debian jessie. I have a working setup up to the moment where my ISP decides to reassign a new WAN IP by reconnecting my DSL-link. After such a reconnect the router itself has an online connection, but masquerading doesn't work any more.

nftable setup before reconnect:

# nft list table nat
table ip nat {
    chain prerouting {
            type nat hook prerouting priority 0; policy accept;
    }

    chain postrouting {
            type nat hook postrouting priority 100; policy accept;
            oif ppp0 masquerade
    }
}

nftable setup after reconnect:

# nft list table nat
table ip nat {
    chain prerouting {
            type nat hook prerouting priority 0; policy accept;
    }

    chain postrouting {
            type nat hook postrouting priority 100; policy accept;
            oif 8 masquerade
    }
}

So I assume the downtime of ppp0 during the reconnect causes the related rules to be some kind of unassigned. Manually re-applying the nft rules (flush + add) solves this problem until the next reconnect.

How can I ensure the temporarily disabled rules will be automatically reassigned to ppp0 after the connection has been re-established?

debian nftables point-to-point-protocol pppoe reconnect

1 Answers

  1. Best Answer

    I finally figured out how to solve this issue.

    # nft list table nat
table ip nat {
    chain prerouting {
        type nat hook prerouting priority 0; policy accept;
    }

    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        oifname "ppp0" masquerade
    }
}

    You just have to use iifname/oifname "ppp0" instead of oif/iif ppp0. The latter addresses the interface by string rather than using the interface id. The quotes are optional, but I think it emphasizes the different interpretation well.

    The manpage simply states:

    Type ifname: Interface name (16 byte string). Does not have to exist.

    I don't know if there's any downside like performance impacts when matching, but it feels like it's the correct solution.

    • 1