* nftables port forward on DHCP interface to static IP
@ 2021-04-18 15:59 Pekka Järvinen
2021-04-18 19:23 ` Frank Myhr
0 siblings, 1 reply; 6+ messages in thread
From: Pekka Järvinen @ 2021-04-18 15:59 UTC (permalink / raw)
To: netfilter
Hi,
I'm trying to setup port forward for interface which uses DHCP. I
don't want to reference the interface's public IP in a rule. Is it
possible? My attempt:
iifname $wanif tcp dport {12345} dnat ip to 192.168.1.11
Error: Could not process rule: No such file or directory
Kernel 5.11.2.
define wanif = wan0
define lanif = lan0
define home_net = 192.168.1.0/24
define home_net_gw = 192.168.1.1
table inet filter {
# ...
chain prerouting {
type nat hook prerouting priority dstnat; policy accept;
ct state invalid drop
}
chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
ct state invalid drop
oifname $wanif masquerade persistent comment "MasqNAT"
drop
}
}
--
Pekka Järvinen
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: nftables port forward on DHCP interface to static IP
2021-04-18 15:59 nftables port forward on DHCP interface to static IP Pekka Järvinen
@ 2021-04-18 19:23 ` Frank Myhr
2021-04-19 17:22 ` Pekka Järvinen
0 siblings, 1 reply; 6+ messages in thread
From: Frank Myhr @ 2021-04-18 19:23 UTC (permalink / raw)
To: Pekka Järvinen, netfilter
On 2021/04/18 11:59, Pekka Järvinen wrote:
> Hi,
>
> I'm trying to setup port forward for interface which uses DHCP. I
> don't want to reference the interface's public IP in a rule. Is it
> possible? My attempt:
>
> iifname $wanif tcp dport {12345} dnat ip to 192.168.1.11
Hi Pekka,
Try:
iifname $wanif tcp dport 12345 dnat 192.168.1.11
or
iifname $wanif tcp dport {12345} dnat 192.168.1.11
(but the braces are unnecessary unless you want to add more than one dport)
https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT)#Destination_NAT
Best Regards,
Frank
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: nftables port forward on DHCP interface to static IP
2021-04-18 19:23 ` Frank Myhr
@ 2021-04-19 17:22 ` Pekka Järvinen
2021-04-19 21:20 ` Frank Myhr
0 siblings, 1 reply; 6+ messages in thread
From: Pekka Järvinen @ 2021-04-19 17:22 UTC (permalink / raw)
To: Frank Myhr; +Cc: netfilter
On Sun, 18 Apr 2021 at 22:23, Frank Myhr <fmyhr@fhmtech.com> wrote:
>
> Hi Pekka,
>
> Try:
> iifname $wanif tcp dport 12345 dnat 192.168.1.11
>
> or
> iifname $wanif tcp dport {12345} dnat 192.168.1.11
> (but the braces are unnecessary unless you want to add more than one dport)
>
> https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT)#Destination_NAT
Thanks. I managed to fix it just moments ago. I had remnants of
iptables kernel modules which I blacklisted:
# cat /etc/modprobe.d/blacklist.conf
blacklist ip_tables
blacklist iptable_nat
I also upgraded kernel to 5.11.14.
This might have caused the whole line erroring earlier.
I moved NAT related stuff to ip (IPv4) filter instead of inet:
define wanif = wan0
define lanif = lan0
define home_net = 192.168.1.0/24
define home_net_gw = 192.168.1.1
# Port forwards
define port_fwd_ip = 192.168.1.11
define port_fwds_udp = {12345}
define port_fwds_tcp = {54321}
# IPv4 & IPv6
table inet filter {
# ...
chain forward {
type filter hook forward priority filter; policy drop;
ct state invalid drop
# ...
# Port forward WAN -> LAN
iifname $wanif oifname $lanif tcp dport $port_fwds_tcp accept
comment "Accept forwarded TCP"
iifname $wanif oifname $lanif udp dport $port_fwds_udp accept
comment "Accept forwarded UDP"
}
# ...
}
# IPv4
table ip filter {
# NAT
chain prerouting {
type nat hook prerouting priority dstnat; policy accept;
ct state invalid drop
# TCP SYN (CT NEW)
tcp flags & (fin|syn|rst|ack) != syn ct state {new} drop
# Port forward WAN -> LAN
iifname $wanif tcp dport $port_fwds_tcp dnat to $port_fwd_ip
comment "Port forwards TCP"
iifname $wanif udp dport $port_fwds_udp dnat to $port_fwd_ip
comment "Port forwards UDP"
}
# NAT
chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
ct state invalid drop
oifname $wanif masquerade persistent comment "MasqNAT"
}
}
--
Pekka Järvinen
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: nftables port forward on DHCP interface to static IP
2021-04-19 17:22 ` Pekka Järvinen
@ 2021-04-19 21:20 ` Frank Myhr
2021-04-19 21:51 ` Florian Westphal
0 siblings, 1 reply; 6+ messages in thread
From: Frank Myhr @ 2021-04-19 21:20 UTC (permalink / raw)
To: Pekka Järvinen; +Cc: netfilter
On 2021/04/19 13:22, Pekka Järvinen wrote:
> On Sun, 18 Apr 2021 at 22:23, Frank Myhr <fmyhr@fhmtech.com> wrote:
>>
>> Hi Pekka,
>>
>> Try:
>> iifname $wanif tcp dport 12345 dnat 192.168.1.11
>>
>> or
>> iifname $wanif tcp dport {12345} dnat 192.168.1.11
>> (but the braces are unnecessary unless you want to add more than one dport)
>>
>> https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT)#Destination_NAT
>
> Thanks. I managed to fix it just moments ago.
Great! Thanks for reporting back. A few comments:
> I had remnants of iptables kernel modules which I blacklisted:
>
> # cat /etc/modprobe.d/blacklist.conf
> blacklist ip_tables
> blacklist iptable_nat
Good to have those out of the way.
> I also upgraded kernel to 5.11.14.
Probably not necessary, but think it can't hurt.
> This might have caused the whole line erroring earlier.
Yes, recent nftables / kernels have improved error reporting. But you
were already on 5.11.2... so probably not much difference.
> I moved NAT related stuff to ip (IPv4) filter instead of inet:
Two comments:
1) Mea culpa! I didn't read your original ruleset carefully enough. Just
looking at it quickly I thought you had a trivial syntax error. But now
I see:
a) Your original rule in inet table:
iifname $wanif tcp dport {12345} dnat ip to 192.168.1.11
looks fine to me according to syntax at
https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT)#Inet_family_NAT
I don't think it should be necessary to move from inet to ip table to
get this to work. You might have encountered a bug which should be reported.
Could you please check the version of your nft command?:
nft -v
b) The other part of the syntax error I mistakenly thought I spotted is
whether or not to include the "to" keyword, i.e. "dnat to {ip}" vs. just
"dnat {ip}". Looking at nftables source parser_bison.y it appears to me
that the "to" is optional in case of nat in ip (IPv4) table but
NECESSARY when doing nat in inet table. The nft man page uses "dnat to",
whereas the wiki uses bare "nat" in places. 'nft list ruleset' always
includes the "to". I will update the wiki to include the "to" in all
cases: it seems a good habit since inet table requires it.
> define wanif = wan0
> define lanif = lan0
> define home_net = 192.168.1.0/24
> define home_net_gw = 192.168.1.1
>
> # Port forwards
> define port_fwd_ip = 192.168.1.11
> define port_fwds_udp = {12345}
> define port_fwds_tcp = {54321}
>
> # IPv4 & IPv6
> table inet filter {
Nitpick: just in my personal opinion, better not to use table name that
is a nftables keyword ("filter"). I know the wiki does it lots of
places. And it's not technically wrong. But:
a) There have been recent bugs (hopefully now all fixed!) from nft
confusing a user-named object with a reserved keyword.
b) Again just in my opinion, it makes the ruleset harder to read: *I*
have to determine whether a word is a keyword or a label from its context.
> # ...
>
> chain forward {
> type filter hook forward priority filter; policy drop;
> ct state invalid drop
>
> # ...
>
> # Port forward WAN -> LAN
> iifname $wanif oifname $lanif tcp dport $port_fwds_tcp accept
> comment "Accept forwarded TCP"
> iifname $wanif oifname $lanif udp dport $port_fwds_udp accept
> comment "Accept forwarded UDP"
> }
>
> # ...
>
> }
>
> # IPv4
> table ip filter {
>
> # NAT
> chain prerouting {
> type nat hook prerouting priority dstnat; policy accept;
> ct state invalid drop
>
> # TCP SYN (CT NEW)
> tcp flags & (fin|syn|rst|ack) != syn ct state {new} drop
You're filtering in a nat chain, generally not a good idea. My
understanding is that, since nat is based on connection tracking, this
chain will see only the FIRST packet of each connection. You probably
want additional rules in a filter chain (maybe you already have them in
the #... in your forward chain).
You could add counters (if only temporarily) to your rules in your nat
and filter chains and see where packets are getting handled.
Also a nitpick: no need for {} around the state here.
>
> # Port forward WAN -> LAN
> iifname $wanif tcp dport $port_fwds_tcp dnat to $port_fwd_ip
> comment "Port forwards TCP"
> iifname $wanif udp dport $port_fwds_udp dnat to $port_fwd_ip
> comment "Port forwards UDP"
> }
>
> # NAT
> chain postrouting {
> type nat hook postrouting priority srcnat; policy accept;
> ct state invalid drop
> oifname $wanif masquerade persistent comment "MasqNAT"
> }
> }
>
Best regards,
Frank
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: nftables port forward on DHCP interface to static IP
2021-04-19 21:20 ` Frank Myhr
@ 2021-04-19 21:51 ` Florian Westphal
2021-04-20 1:21 ` Frank Myhr
0 siblings, 1 reply; 6+ messages in thread
From: Florian Westphal @ 2021-04-19 21:51 UTC (permalink / raw)
To: Frank Myhr; +Cc: Pekka Järvinen, netfilter
Frank Myhr <fmyhr@fhmtech.com> wrote:
> Nitpick: just in my personal opinion, better not to use table name that is a
> nftables keyword ("filter"). I know the wiki does it lots of places. And
> it's not technically wrong. But:
"filter" is not a reserved keyword.
> > # TCP SYN (CT NEW)
> > tcp flags & (fin|syn|rst|ack) != syn ct state {new} drop
>
> You're filtering in a nat chain, generally not a good idea. My understanding
> is that, since nat is based on connection tracking, this chain will see only
> the FIRST packet of each connection.
Correct.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: nftables port forward on DHCP interface to static IP
2021-04-19 21:51 ` Florian Westphal
@ 2021-04-20 1:21 ` Frank Myhr
0 siblings, 0 replies; 6+ messages in thread
From: Frank Myhr @ 2021-04-20 1:21 UTC (permalink / raw)
To: Florian Westphal; +Cc: Pekka Järvinen, netfilter
Hi Florian,
On 2021/04/19 17:51, Florian Westphal wrote:
> Frank Myhr <fmyhr@fhmtech.com> wrote:
>> Nitpick: just in my personal opinion, better not to use table name that is a
>> nftables keyword ("filter"). I know the wiki does it lots of places. And
>> it's not technically wrong. But:
>
> "filter" is not a reserved keyword.
Yes, I almost didn't say anything... maybe like vi vs. emacs it's better
to keep my opinion to myself. Actually when looking at a whole ruleset I
don't much care one way or another. My problem comes when using the
command line; when I see something like:
nft add rule inet filter prerouting iifname wan0 tcp dport 12345 count
... there's a pretty good chance I'll mistake that for a filter chain.
(Whereas in the OP ruleset it's a nat chain.) Even checking the ruleset
I might miss the nat/filter chain distinction unless I'm careful. For
me, naming things as above is error-prone and forces a mental load I
could allocate more productively elsewhere.
Since (from a user's perspective) the only purpose of tables is to group
objects with same family, I've taken to calling them something like
"t_inet". And throwing all inet objects in there so that sets & maps can
be shared most widely among them.
>> You're filtering in a nat chain, generally not a good idea. My understanding
>> is that, since nat is based on connection tracking, this chain will see only
>> the FIRST packet of each connection.
>
> Correct.
Thanks for confirming. :-)
Best Wishes,
Frank
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-04-20 1:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-18 15:59 nftables port forward on DHCP interface to static IP Pekka Järvinen
2021-04-18 19:23 ` Frank Myhr
2021-04-19 17:22 ` Pekka Järvinen
2021-04-19 21:20 ` Frank Myhr
2021-04-19 21:51 ` Florian Westphal
2021-04-20 1:21 ` Frank Myhr
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.