Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #265833 > unrolled thread

nftables firewall question: matching udp in ipv6

Back to article view | Back to linux.debian.user

Contents

  nftables firewall question: matching udp in ipv6 Ralph Aichinger <ra@h5.or.at> - 2024-01-12 16:40 +0100
    Re: nftables firewall question: matching udp in ipv6 Tom Furie <tom@furie.org.uk> - 2024-01-12 17:00 +0100
      Re: nftables firewall question: matching udp in ipv6 Ralph Aichinger <ra@h5.or.at> - 2024-01-12 17:30 +0100
      Re: nftables firewall question: matching udp in ipv6 Ralph Aichinger <ra@h5.or.at> - 2024-01-12 17:40 +0100
    Re: nftables firewall question: matching udp in ipv6 Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-01-12 18:30 +0100
      Re: nftables firewall question: matching udp in ipv6 Ralph Aichinger <ra@h5.or.at> - 2024-01-12 19:10 +0100
    Re: nftables firewall question: matching udp in ipv6 Michel Verdier <mv524@free.fr> - 2024-01-12 19:40 +0100
      Re: nftables firewall question: matching udp in ipv6 Ralph Aichinger <ra@h5.or.at> - 2024-01-12 21:20 +0100
        Re: nftables firewall question: matching udp in ipv6 Michel Verdier <mv524@free.fr> - 2024-01-12 22:10 +0100

#265833 — nftables firewall question: matching udp in ipv6

Hello!

I am currently fighting with the following problem: I've got a system
that has 3 relevant interfaces: ppp0, en0 and en2, for external,
internal and dmz respectively. 

The dmz is IPv6 only, a homelab testbed more or less.

I've got the follwing rules in /etc/nftables.conf for ipv6 (i am
abreviating the chain input, because i am only fighting with
forwarding):

table ip6 filter {
        chain input {
                ...
        }

        
    chain forward {
          type filter hook forward priority 0; policy drop;

          iifname ppp0 oifname en0 ct state established,related accept
          iifname en0 oifname ppp0 accept
                                        
          iifname en2 oifname ppp0 accept
          iifname ppp0 oifname en2 accept

          iifname en0 oifname en2 accept
          iifname en2 oifname en0 ct state established,related accept

          meta l4proto ipv6-icmp accept
     

        }
}

This "almost" works: I can do everything I want from my internal
network (connected to en0) towards the outside, and tcp connections
from and to the dmz also work. Ping works everywhere.

What does not work, and this puzzles me, is that UDP does not work. 
E.g. if I lookup a DNS name in my dmz (connected to en2), I see no
udp packets if i start tcpdump on the external interface ppp0. I see
them entering on en2. 

Why does UDP bevave differently from TCP here? Is this an nftables or
ipv6 specific gotcha?

If I insert the following rule at the bottom, everything starts to
work:

meta l4proto  udp  accept

but I don't know how to limit this over broad rule (so it does not
forward UDP to the internal network on en0, which I do not want). 
trying e.g. 

iifname en2 oifname ppp0 meta l4proto  udp  accept
iifname ppp0 oifname en0 meta l4proto  udp  accept

did not work either, ad behaved like my initial setup described on top.

Any hints for me?
TIA
Ralph 

[toc] | [next] | [standalone]

#265834

Ralph Aichinger <ra@h5.or.at> writes:

> I am currently fighting with the following problem: I've got a system
> that has 3 relevant interfaces: ppp0, en0 and en2, for external,
> internal and dmz respectively. 
>
> The dmz is IPv6 only, a homelab testbed more or less.
>
> I've got the follwing rules in /etc/nftables.conf for ipv6 (i am
> abreviating the chain input, because i am only fighting with
> forwarding):
>
> table ip6 filter {
>         chain input {
>                 ...
>         }
>
>         
>     chain forward {
>           type filter hook forward priority 0; policy drop;
>
>           iifname ppp0 oifname en0 ct state established,related accept
>           iifname en0 oifname ppp0 accept
>                                         
>           iifname en2 oifname ppp0 accept
>           iifname ppp0 oifname en2 accept
>
>           iifname en0 oifname en2 accept
>           iifname en2 oifname en0 ct state established,related accept
>
>           meta l4proto ipv6-icmp accept
>      
>
>         }
> }
>
> What does not work, and this puzzles me, is that UDP does not work. 
> E.g. if I lookup a DNS name in my dmz (connected to en2), I see no
> udp packets if i start tcpdump on the external interface ppp0. I see
> them entering on en2. 
>
Where is the DNS server the dmz host is resolving against? In your dmz,
your internal network, on the firewall machine, outside? You may have
other input/output rules that are interfering, but since you've abridged
your ruleset we have no way of knowing.

[toc] | [prev] | [next] | [standalone]

#265838

On Fri, Jan 12, 2024 at 03:52:46PM +0000, Tom Furie wrote:
> Where is the DNS server the dmz host is resolving against? In your dmz,
> your internal network, on the firewall machine, outside? You may have
> other input/output rules that are interfering, but since you've abridged
> your ruleset we have no way of knowing.

 
I've tried this with the public Gooogle DNS 2001:4860:4860::8888. The
behaviour seems consistent: If I try to resolve names over UDP with the
first ruleset I posted, it fails. If I try DNS over TCP (by using 
nslookup with the "-vc" option, it works.

Thanks,
Ralph

[toc] | [prev] | [next] | [standalone]

#265840

On Fri, Jan 12, 2024 at 03:52:46PM +0000, Tom Furie wrote:
> other input/output rules that are interfering, but since you've abridged
> your ruleset we have no way of knowing.

Sorry, wanted to include the full rulest an forgot. I've still have left
off the "table ip nat" and "table ip filter" chains, I hope this is OK.


#!/usr/sbin/nft -f

flush ruleset

table ip nat {
...
}

table ip filter {
...
}

table ip6 filter {
        chain input {
                type filter hook input priority 0; policy drop;
                ct state invalid counter drop comment "early drop of invalid packets"
                ct state {established, related} counter accept comment "accept all connections related to connections made by us"
                iif lo accept comment "accept loopback"
                iif != lo ip6 daddr ::1/128 counter drop comment "drop connections to loopback not coming from loopback"
                meta l4proto ipv6-icmp counter accept comment "accept all ICMP types"
                tcp dport 22 counter accept comment "accept SSH"
                tcp dport 25 counter accept comment "accept SMTP"
                tcp dport 53 counter accept comment "accept DNS"
                udp dport 53 counter accept comment "accept DNS"
                tcp dport 80 counter accept comment "accept HTTP"
                tcp dport 443 counter accept comment "accept HTTPS"
                counter comment "count dropped packets"
        }

        
        chain forward {
                type filter hook forward priority 0; policy drop;

                iifname ppp0 oifname en0 ct state established,related accept
                iifname en0 oifname ppp0 accept
                                        
                iifname en2 oifname ppp0 accept
                iifname ppp0 oifname en2 accept

                iifname en0 oifname en2 accept
                iifname en2 oifname en0 ct state established,related accept

                meta l4proto ipv6-icmp accept

        }
}

[toc] | [prev] | [next] | [standalone]

#265843

On 12 Jan 2024 16:19 +0100, from ra@h5.or.at (Ralph Aichinger):
> If I insert the following rule at the bottom, everything starts to
> work:
> 
> meta l4proto  udp  accept
> 
> but I don't know how to limit this over broad rule (so it does not
> forward UDP to the internal network on en0, which I do not want). 

My suggestion would be to insert a "udp log" rule. (Pretty sure you
only need "udp", not "meta l4proto udp".)

That will give you a firehose of information which will include ports,
interfaces and other relevant information. You can then narrow it down
until it logs the traffic you want to accept, at which point you can
change the "log" action into an "accept" action.

Note that forwarding and filtering can interact in non-intuitive ways.
You may need to add corresponding log rules to each relevant chain,
maybe with a prefix to tell them apart.

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

[toc] | [prev] | [next] | [standalone]

#265846

On Fri, Jan 12, 2024 at 05:26:57PM +0000, Michael Kjörling wrote:
> My suggestion would be to insert a "udp log" rule. (Pretty sure you
> only need "udp", not "meta l4proto udp".)
  
Thanks,  I will try that. Yes "meta l4proto udp" might be cargo 
cult configuration ;)

> That will give you a firehose of information which will include ports,
> interfaces and other relevant information. You can then narrow it down
> until it logs the traffic you want to accept, at which point you can
> change the "log" action into an "accept" action.
> 
> Note that forwarding and filtering can interact in non-intuitive ways.
> You may need to add corresponding log rules to each relevant chain,
> maybe with a prefix to tell them apart.
  
Thanks a lot!

Ralph

[toc] | [prev] | [next] | [standalone]

#265848

On 2024-01-12, Ralph Aichinger wrote:

> If I insert the following rule at the bottom, everything starts to
> work:
>
> meta l4proto  udp  accept

Add log to see what would be dropped:

  meta l4proto udp log level info prefix "udp" accept

Provide "nft list ruleset" to better see what nft understands.

I suppose your udp is not "established" to not be accepted. Perhaps
something in your nat that breaks "established" ?

[toc] | [prev] | [next] | [standalone]

#265853

On Fri, Jan 12, 2024 at 07:35:14PM +0100, Michel Verdier wrote:
>   meta l4proto udp log level info prefix "udp" accept

Thanks for that, and thanks to Michael Kjörling, your replies really
helped.

I found log lines similar to:

2024-01-12T19:51:32.999346+01:00 pi kernel: [3401524.305759] ralphfilterudpIN=en2 OUT=en2 MAC=08:00:1e:02:00:02:6c:cf:39:00:42:f4:86:dd SRC=2a02:0ab8:redacted DST=2a00:63c1:redacted LEN=96 TC=0 HOPLIMIT=63 FLOWLBL=279176 PROTO=UDP SPT=40840 DPT=123 LEN=56 

with interestingly IN and OUT interfaces the same en2 (=dmz). And to my surprise, I
found a double IPv6 default route:

default via fe80::e25f:b9ff:fe1e:a100 dev ppp0 proto ra metric 1024 expires 1791sec hoplimit 64 pref medium
default via fe80::a00:1eff:fe01:0 dev en2 proto ra metric 1024 expires 1588sec hoplimit 64 pref medium

Now I don't understand why pings/ICMP and tcp traffic seem to decide for
the correct route via ppp0 and only udp sems to prefer the one via en2,
but when I delete it, everything works. So while nftables might still 
contain some problematic stuff, at the core of my problem seems to be
routing.

I "only" have to find out what mechanism adds the lower, en2 default
route within a few minutes, once I delete it. I ran "radvdump", but
that only dumped the correct announcement my provider sends for the
net over the PPPoE connection. Hm.

Thanks everybody, of course hints on how to find out what's adding
default routes would also be appreciated ;)

Ralph

[toc] | [prev] | [next] | [standalone]

#265855

On 2024-01-12, Ralph Aichinger wrote:

> I "only" have to find out what mechanism adds the lower, en2 default
> route within a few minutes, once I delete it. I ran "radvdump", but
> that only dumped the correct announcement my provider sends for the
> net over the PPPoE connection. Hm.
>
> Thanks everybody, of course hints on how to find out what's adding
> default routes would also be appreciated ;)

It depends on how you setup your network. If you only use ifupdown (and
it is better for a server) look in /etc/network/interfaces and
/etc/network/interfaces.d/* for "gateway" stances

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web