HELP: fw4/nftables and PPTP server

Hello,
After upgrading to OpenWrt version 22.03.0, I have issue configuring PPTP server:

I successfully installed the PPTP server package and I can connect from a remote machine and after that, I can also ping to my router internal IP and login to luci.
The issue is that I cannot access my internal LAN IPs (192.168.18.x) except the internal IP of my router (192.168.18.254).
Up to OpenWrt version 22.02.0 I could solve this with the command iptables -A forwarding_rule -i "$ifname" -j ACCEPT inside the file /etc/ppp/ip-up.
But it does not work anymore with OpenWrt version 22.03.0/fw4/nftables and I have no clue how it should be done (I have read all the wiki pages regarding PPTP/firewall with no success).

Please help,
Regrards.

My /etc/config/pptpd configuration is like this:

config service 'pptpd'
        option 'enabled' '1'
        option 'localip' '192.168.18.254'
        option 'remoteip' '192.168.18.250-253'

config 'login'
        option 'username' 'user1'
        option 'password' 'pass123'

Problem

You need a similar approach as described here:

Basically add the PPP device (ppp0 ?) as Covered device to the zone responsible for the network you want to reach, lan in your case.

1 Like

I'm afraid it did not help.

Run nft list chain inet fw4 forward | grep forward_lan to check if the ppp interface is there

iifname { "ppp0", "br-lan" } jump forward_lan ...

The analogous nft rule is

nft insert rule inet fw4 forward iifname "ppp*" counter accept

You could run it to see if it makes a difference.

Do you have the option to change your VPN protocol? If you control both sides of the tunnel, you presumably can do this. PPTP is not secure and is considered unsuitable for the modern internet threat landscape.

I'd recommend Wireguard as a replacement -- it's available for Mac, Linux, Windows, iOS, and Android (and obviously OpenWrt), and is easy to configure. It is also high performance, modern, and secure.

This command works :slight_smile:

So my solution is to create :
/etc/ppp/ip-up

#!/bin/sh
ifname=$1

if [[ ${ifname} != *"wan"* ]]
then
    nft insert rule inet fw4 forward iifname "$ifname" counter accept
fi

and
/etc/ppp/ip-down

ifname=$1

if [[ ${ifname} != *"wan"* ]]
then
    hrule=`nft -a list chain inet fw4 forward | grep "$ifname" | awk '{print $(N
F)}'`
    nft delete rule inet fw4 forward handle $hrule
fi

Thank you!

So what is the actual ifname in your case? My suggested solution should've worked and I would like to know why it didn't. I'd rather not see custom ppp-up/ppp-down scripts staging broad forward allow rules as canonical solution as it will be copied by future readers without much thought.

ifname is ppp0 but sometimes its ppp1 (is ppp* a valid interface?)

The wildcard character * is the nft's equivalent of the iptables' +.

As far as I can tell, wildcards are not honored by uci at the moment.

root@OpenWrt:~# uci add_list firewall.@zone[0].device="ppp*"
root@OpenWrt:~# fw4 restart
/dev/stdin:34:3-9: Error: Byteorder mismatch: expected big endian, got host endian
                iifname { "br-lan", "ppp*" } jump input_lan comment "!fw4: Handle lan IPv4/IPv6 input traffic"
                ^^^^^^^
The rendered ruleset contains errors, not doing firewall restart.
root@OpenWrt:~#

If you use ppp0 or ppp1 as interface/device name(s), restarting the service will not return an error and the rules will be created correctly.

The interface number is chosen randomly by the OS, so it looks like I'm stuck with ip-up script.

They should be actually. fw4 still uses + in order to stay compatible with existing configurations. It will translate it to * internally. (See also 0bc844ba02ae460d4a895878b9136ba5d8e09b37) However...

... looks like an actual endianess bug in nftables itself.

1 Like

If the asterisk is escaped, it seems to work ok.

nft -c add rule inet fw4 input iifname { "br-lan", "ppp\*" } jump input_lan

EDIT: Although this could just be a literal interpretation of the asterisk as jow points out below.

Question is whether it actually does wildcard matching then, or attempting to match a literal ppp* ifname.

1 Like

This was already fixed in nftables 1.0.3 in master, but 22.03 is still on nftables 1.0.2.

http://git.netfilter.org/nftables/commit/?id=806ab081dc9ae3ea313ae9e471ee1c97c7a9e2ad

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.