search for: iifnam

...: x86_64 OS: All Status: NEW Severity: normal Priority: P5 Component: nft Assignee: pablo at netfilter.org Reporter: ian.kumlien at gmail.com if you do: define $interfaces = { tun*, lo } and then using that variable: iifname $interfaces accept results in: Error: Byteorder mismatch: expected big endian, got host endian but if i do: iifname tun* accept it works. This, is odd, and should be fixed ;) nft 0.8.3 -- You are receiving this mail because: You are watching all bug changes. -------------- next part -------...

https://bugzilla.netfilter.org/show_bug.cgi?id=1360 Bug ID: 1360 Summary: BUG: invalid expression type concat on invalid input "iifname . oifname p . q" Product: nftables Version: unspecified Hardware: x86_64 OS: Debian GNU/Linux Status: NEW Severity: normal Priority: P5 Component: nft Assignee: pablo at netfilter.org...

...issue is only present with filters for tcp ports but this is just a guess. Here is what my ip input filter chain looks like: table ip filter { chain INPUT { type filter hook input priority 0; policy accept; ct state established,related accept iifname "eth0" tcp dport { 22, 80, 443 } counter accept iifname "lo" accept tcp dport 80 counter iifname "eth0" tcp dport 80 counter iifname "eth0" tcp dport { 80, 111 } counter iifname...

...6_64 OS/Version: All Status: NEW Severity: normal Priority: P5 Component: nft AssignedTo: pablo at netfilter.org ReportedBy: loki at lokis-chaos.de Estimated Hours: 0.0 nft shows extra symbols. I could reproduce this at least for iifname. The extra symbols are not shown if the output is not the tty: fwtest01 ~ # nft -i nft> table filter nft> add chain filter input nft> add rule filter input meta iifname "lo" accept nft> list table filter table ip filter { chain input { meta iifname...

...type inet_proto elements = { icmp, icmpv6 } } set allowed_tcp_dports { type inet_service elements = { ssh } } chain allow { ct state established,related accept meta l4proto @allowed_protocols accept iifname @allowed_interfaces accept tcp dport @allowed_tcp_dports accept } chain input { type filter hook input priority filter + 10; policy accept jump allow reject with icmpx type port-unreachable } } which, at a f...

...aster compilation log OS: Arch Linux Kernel: Linux 5.2.2-arch1-1-ARCH nftables: v0.9.1 With the following `/etc/nftables.conf` file: #!/sbin/nft -f define ifs = {lo} table inet filter { chain input { type filter hook input priority 0; policy drop; } } inet filter input iifname $ifs accept The atomic rule replacement gives the following error: $ nft flush ruleset ';' include '"/etc/nftables.conf"' In file included from (null):1:17-51: /etc/nftables.conf:13:19-37: Error: Could not process rule: No such file or directory inet filter inpu...

...t: nftables Version: unspecified Hardware: x86_64 OS: All Status: NEW Severity: enhancement Priority: P5 Component: nft Assignee: pablo at netfilter.org Reporter: ville.skytta at iki.fi ...at least in iifname, oifname. Not a problem otherwise for the system to have interface names starting with a number that I can see. For example: # ip link show dev 5af3c3f0 14: 5af3c3f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc [...] # nft add rule inet filter forward iifname 5af3c3f0 jump meh Error:...

...ilter.org Reporter: trever at middleearth.sapphiresunday.org >From a script that works with plain iptables: iptables -A INPUT -i \!ppp0 -p udp --destination-port 53 -j ACCEPT # iptables-nft -A INPUT -i \!ppp0 -p tcp --destination-port 53 -j ACCEPT does not work! In part it yields: iifname "!ppp0" ip protocol tcp counter packets 0 bytes 0 accept in nft list ruleset I believe that is supposed to be iifname != "ppp0" ip protocol tcp counter packets 0 bytes 0 accept. I am afraid my attempts at finding why this is have not yielded any good results. This is the...

...t;accept": null}]}}}, {"insert": {"rule": {"family": "inet", "table": "firewalld", "chain": "filter_INPUT_ZONES", "expr": [{"match": {"left": {"meta": {"key": "iifname"}}, "op": "==", "right": "eth1"}}, {"goto": {"target": "filter_IN_internal"}}]}}}, {"insert": {"rule": {"family": "inet", "table": "firewalld", "chain":...

...OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: nft AssignedTo: pablo at netfilter.org ReportedBy: anarey at gmail.com Estimated Hours: 0.0 We add the following rule: sudo nft add rule ip test input meta iifname {eth0, wlan0} or sudo nft add rule ip test input meta iifname {"eth0", "wlan0"} and nft lists it: $ sudo nft list table ip test table ip test { chain input { iifname { "", "" } } } -- Configure bugmail: https://bugzilla.netfilter.org/user...

...Severity: minor Priority: P5 Component: nft Assignee: pablo at netfilter.org Reporter: ian.kumlien at gmail.com This might be known, 0.7 is old - but if it isn't then... ;) I added two rules like this in table nat, chain prerouting (with a hook): iifname $ext_if ip saddr $external_dns_servers tcp dport $external_dns_ports dnat to numgen inc mod 3 map { 0: 10.0.0.2, 1: 10.0.0.3, 2: 10.0.0.4 } iifname $ext_if ip saddr $external_dns_servers udp dport $external_dns_ports dnat to numgen inc mod 3 map { 0: 10.0.0.2, 1: 10.0.0.3, 2: 10.0.0.4 } And they...

...t: nft Assignee: pablo at netfilter.org Reporter: slyfox at inbox.ru # This report is a valid nft file. # $ uname -r # 4.14.0-rc5-00009-g3728e6a255b5 # run as: 'nft -f nft.bug' # This will output: # table inet filter { # chain local-input { # iifname "lo" meta nfproto ipv4 payload @nh,96,64 0x7f0000017f000001 [invalid type] ip protocol udp counter packets 0 bytes 0 accept # } # } # While when we run 'list ruleset' right afterwards decoding is fine: # table inet filter { # chain local-input { #...

...tus: NEW Severity: minor Priority: P5 Component: nft Assignee: pablo at netfilter.org Reporter: alzeih at gmail.com I'm experiencing a SIGABRT when using nft with a particular rule, when I was expecting a parse error instead. The rule is: "iifname ens3 snat to 10.0.0.0/28" Command output: # nft -f /etc/nftables.conf BUG: unknown expression type prefix nft: netlink_linearize.c:688: netlink_gen_expr: Assertion `0' failed. Aborted (core dumped) With the following ruleset file: #!/usr/bin/nft -f # ipv4/ipv6 Simple & Safe Fire...

...OS: Debian GNU/Linux 10 (Buster) Kernel: 4.19.0-8-amd64 This works every time: # nft -f - << EOF flush ruleset add table ip filter add chain ip filter forward { type filter hook forward priority 0; policy accept; } add map ip filter foo { type ifname : verdict; } add rule ip filter forward iifname vmap @foo add element ip filter foo { "dummy0" : accept } add element ip filter foo { "dummy0" : accept } EOF While these do not: # nft -f - << EOF flush ruleset add table ip filter add chain ip filter forward { type filter hook forward priority 0; policy accept; } add m...

....org Reporter: kees.dejong+dev at neobits.nl Tested and confirmed the following bug on Debian 10 (nftables-0.9.0-2 on kernel 5.4.51-v7l+) and Fedora 32 (nftables-0.9.3-3.fc32.x86_64 on kernel 5.8.12-200.fc32.x86_64). I use the following command: `nft add rule inet firewalld filter_INPUT iifname "eth0" ip saddr { 172.27.10.0/24, 172.27.11.0/24 } ip daddr 172.27.10.0/24 ct state new accept` Which is processed in the running configuration as: `iifname "eth0" ip saddr { 172.27.10.0/23 } ip daddr 172.27.10.0/24 ct state new accept` Notice that the subnet has become /23 i...

https://bugzilla.netfilter.org/show_bug.cgi?id=1145 Bug ID: 1145 Summary: nft 0.7: expression.c:966: range_expr_value_low: Assertion '0' failed. Product: nftables Version: unspecified Hardware: x86_64 OS: Gentoo Status: NEW Severity: normal Priority: P5

...vior: * Nested, implicit chains could be used * Any errors would be identified in the "source" (rather than process abort) --- $ cat nested-chain-failure.nft table inet global { chain prerouting_pre_nat { type filter hook prerouting priority mangle - 1; policy accept iifname eth0 jump { ip version 4 jump { ip version 4 accept } } } } $ cat without-nest.nft table inet global { chain prerouting_pre_nat { type filter hook prerouting priority mangle - 1; policy accept iifname eth0 jump { ip version 4 accep...

...uot;/etc/nftables/init.nft") at libnftables.c:508 #20 0x000055555556acb9 in main (argc=<optimized out>, argv=0x7fffffffe1c8) at main.c:455 When it is adding the rules and echoing, the output is kind of mangled. A rule that looks like table inet filter { chain input_XXXXXXX { iifname { "bond0" } ip saddr { 10.0.0.0/8 } ip daddr { 192.168.1.1 } tcp dport { ssh } counter accept } } Gets echoed as add rule inet filter input_XXXXXXX iifname { "bond0", "bond0" } ip saddr { 10.0.0.0/8, 10.0.0.0/8-0xffffffff [invalid type] } ip daddr { 192.168.1.1,...

https://bugzilla.netfilter.org/show_bug.cgi?id=1674 Bug ID: 1674 Summary: ebtables causing packet loss Product: ebtables Version: unspecified Hardware: x86_64 OS: All Status: NEW Severity: critical Priority: P5 Component: ebtables-nft Assignee: pablo at netfilter.org

...eporter: pgnd at dev-mail.net #!/usr/sbin/nft -f define wan = "eth0" define lan = "eth1" define vpn = "tun0" define server = "10.10.10.1" table nat { chain prerouting { type nat hook prerouting priority -100; policy accept; iifname $wan tcp dport 10000 dnat to $server:10000; } chain postrouting { type nat hook postrouting priority 100; policy accept; oifname $vpn masquerade oifname $wan masquerade } } checks ok, no error nft -c -f tmp.nft (...