All of lore.kernel.org
 help / color / mirror / Atom feed
* Fwd: IP daddr filtering not working for non-routable address
       [not found] <CADjU3LmddfsRShNVx-hArmivM=iUGvEFg28Gd90qyg7VRGqvbw@mail.gmail.com>
@ 2021-09-01  7:40 ` Niko Kortström
  2021-09-01 10:06   ` Kerin Millar
  0 siblings, 1 reply; 6+ messages in thread
From: Niko Kortström @ 2021-09-01  7:40 UTC (permalink / raw)
  To: netfilter

Hi!

We are testing following nftables rules (counters added for debugging purposes):

chain forward {
    type filter hook forward priority filter - 1; policy drop;
    jump ecpri-ip-filtering
}
chain filtering-logging {
    counter packets 0 bytes 0 drop
}
chain ip-filtering {
    iifname "rfo*" counter packets 835 bytes 615040
    iifname "rfo*" ip daddr 172.21.1.18 accept
    iifname "rfo*" counter packets 0 bytes 0
    iifname "gre11E" accept
    iifname "rfo*" counter packets 0 bytes 0
    iifname "lo" accept
    iifname "rfo*" counter packets 0 bytes 0
    goto filtering-logging
}

We are sending test packets from a neighbouring host to an IP address
that cannot be routed on this host.
# tcpdump -i rfoe4.295
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on rfoe4.295, link-type EN10MB (Ethernet), capture size 262144 bytes
09:34:42.657004 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 733
09:34:43.975378 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 325
09:34:44.046110 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 113
09:34:44.187158 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 106
09:34:44.428949 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 347
09:34:44.854991 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 130
09:34:45.284802 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 101
09:34:45.446108 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 733
09:34:46.537990 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 269
09:34:46.572270 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 269
09:34:46.602943 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 269
09:34:46.673617 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 325
09:34:46.754555 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 113

Why are these packets being accepted as daddr matches?


Niko Kortström

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Fwd: IP daddr filtering not working for non-routable address
  2021-09-01  7:40 ` Fwd: IP daddr filtering not working for non-routable address Niko Kortström
@ 2021-09-01 10:06   ` Kerin Millar
       [not found]     ` <CADjU3LnN_uLqZ1LKJcjBCotv+OVJiL7v8xdsdt89_nxHOqHJjw@mail.gmail.com>
  0 siblings, 1 reply; 6+ messages in thread
From: Kerin Millar @ 2021-09-01 10:06 UTC (permalink / raw)
  To: Niko Kortström; +Cc: netfilter

On Wed, 1 Sep 2021 10:40:06 +0300
Niko Kortström <niko.kortstrom@gmail.com> wrote:

> Hi!

Hello.

> 
> We are testing following nftables rules (counters added for debugging purposes):
> 
> chain forward {
>     type filter hook forward priority filter - 1; policy drop;
>     jump ecpri-ip-filtering
> }
> chain filtering-logging {
>     counter packets 0 bytes 0 drop
> }
> chain ip-filtering {
>     iifname "rfo*" counter packets 835 bytes 615040
>     iifname "rfo*" ip daddr 172.21.1.18 accept
>     iifname "rfo*" counter packets 0 bytes 0
>     iifname "gre11E" accept
>     iifname "rfo*" counter packets 0 bytes 0
>     iifname "lo" accept
>     iifname "rfo*" counter packets 0 bytes 0
>     goto filtering-logging
> }
> 
> We are sending test packets from a neighbouring host to an IP address
> that cannot be routed on this host.
> # tcpdump -i rfoe4.295
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on rfoe4.295, link-type EN10MB (Ethernet), capture size 262144 bytes
> 09:34:42.657004 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 733
> 09:34:43.975378 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 325
> 09:34:44.046110 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 113
> 09:34:44.187158 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 106
> 09:34:44.428949 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 347
> 09:34:44.854991 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 130
> 09:34:45.284802 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 101
> 09:34:45.446108 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 733
> 09:34:46.537990 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 269
> 09:34:46.572270 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 269
> 09:34:46.602943 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 269
> 09:34:46.673617 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 325
> 09:34:46.754555 IP 172.22.48.18.54178 > 10.0.0.1.51000: UDP, length 113
> 
> Why are these packets being accepted as daddr matches?

You haven't shown any evidence that these packets are being accepted, whether it be by way of a daddr match or not. Further, the "ecpri-ip-filtering" and "filtering-logging" chains are missing from your ruleset excerpt, making it impossible for a third-party to determine how the mentioned packets are being handled.

-- 
Kerin Millar

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Fwd: IP daddr filtering not working for non-routable address
       [not found]     ` <CADjU3LnN_uLqZ1LKJcjBCotv+OVJiL7v8xdsdt89_nxHOqHJjw@mail.gmail.com>
@ 2021-09-01 11:24       ` Kerin Millar
  2021-09-01 14:59         ` Niko Kortström
       [not found]         ` <CADjU3L=Q=rxK6Oy37SbN=ANXN6ig+rKdkZ_6iU+3j3AYkrY4sQ@mail.gmail.com>
  0 siblings, 2 replies; 6+ messages in thread
From: Kerin Millar @ 2021-09-01 11:24 UTC (permalink / raw)
  To: Niko Kortström; +Cc: netfilter

On Wed, 1 Sep 2021 13:54:51 +0300
Niko Kortström <niko.kortstrom@gmail.com> wrote:

> Hi
> 
> Sorry on we're making some changes and changing the names, on target
> ip-filtering has been changed to ecpri-ip-filtering. How do the packets
> filtered not increase counters past the accept rule if they are not
> accepted by it?

One possibility is that the packet is being considered as a martian as a consequence of reverse path filtering (RFC 3704). In that case, the packet would not be processed by Netfilter at all. You can check the status of the filter(s) by running sysctl -a | grep '\.rp_filter'.

-- 
Kerin Millar

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Fwd: IP daddr filtering not working for non-routable address
  2021-09-01 11:24       ` Kerin Millar
@ 2021-09-01 14:59         ` Niko Kortström
       [not found]         ` <CADjU3L=Q=rxK6Oy37SbN=ANXN6ig+rKdkZ_6iU+3j3AYkrY4sQ@mail.gmail.com>
  1 sibling, 0 replies; 6+ messages in thread
From: Niko Kortström @ 2021-09-01 14:59 UTC (permalink / raw)
  To: Kerin Millar; +Cc: netfilter

Hi

Sorry on we're making some changes and changing the names, on target
ip-filtering has been changed to ecpri-ip-filtering. We're wondering
how do the packets filtered not increase counters past the accept rule
if they are not accepted by it.

# ip netns exec radions sysctl -a | grep '\.rp_filter'.
net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.rfoe4.rp_filter = 0
net.ipv4.conf.rfoe4/295.rp_filter = 0

No martians seem to be logged by the kernel.


Niko Kortström


On Wed, Sep 1, 2021 at 2:24 PM Kerin Millar <kfm@plushkava.net> wrote:
>
> On Wed, 1 Sep 2021 13:54:51 +0300
> Niko Kortström <niko.kortstrom@gmail.com> wrote:
>
> > Hi
> >
> > Sorry on we're making some changes and changing the names, on target
> > ip-filtering has been changed to ecpri-ip-filtering. How do the packets
> > filtered not increase counters past the accept rule if they are not
> > accepted by it?
>
> One possibility is that the packet is being considered as a martian as a consequence of reverse path filtering (RFC 3704). In that case, the packet would not be processed by Netfilter at all. You can check the status of the filter(s) by running sysctl -a | grep '\.rp_filter'.
>
> --
> Kerin Millar

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Fwd: IP daddr filtering not working for non-routable address
       [not found]         ` <CADjU3L=Q=rxK6Oy37SbN=ANXN6ig+rKdkZ_6iU+3j3AYkrY4sQ@mail.gmail.com>
@ 2021-09-01 15:13           ` Kerin Millar
  2021-09-01 16:31             ` Niko Kortström
  0 siblings, 1 reply; 6+ messages in thread
From: Kerin Millar @ 2021-09-01 15:13 UTC (permalink / raw)
  To: Niko Kortström; +Cc: netfilter

On Wed, 1 Sep 2021 16:59:44 +0300
Niko Kortström <niko.kortstrom@gmail.com> wrote:

> Hi
> 
> Sorry on we're making some changes and changing the names, on target
> ip-filtering has been changed to ecpri-ip-filtering. We're wondering how do
> the packets filtered not increase counters past the accept rule if they are
> not accepted by it.
> 
> # ip netns exec radions sysctl -a | grep '\.rp_filter'.
> net.ipv4.conf.all.rp_filter = 2
> net.ipv4.conf.default.rp_filter = 0
> net.ipv4.conf.rfoe4.rp_filter = 0
> net.ipv4.conf.rfoe4/295.rp_filter = 0
> 
> No martians seem to be logged by the kernel.

For them to be logged requires that net.ipv4.conf.*.log_martians be set to a value of 1, where * is either "all" or the link name in question.

Also, you could try adding something like this:-

chain prerouting {
	type filter hook prerouting priority raw; policy accept;
	ip daddr 10.0.0.0/8 meta nftrace set 1
}

In the case that the packet is being processed by Netfilter, you may then determine how it traverses your ruleset by executing "nft monitor trace".

-- 
Kerin Millar

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Fwd: IP daddr filtering not working for non-routable address
  2021-09-01 15:13           ` Kerin Millar
@ 2021-09-01 16:31             ` Niko Kortström
  0 siblings, 0 replies; 6+ messages in thread
From: Niko Kortström @ 2021-09-01 16:31 UTC (permalink / raw)
  To: Kerin Millar; +Cc: netfilter

Hi!

Thanks a lot! With this nft tracing we can see that the packets are
visible in prerouting but not in the forwarding chain, so they are
dropped in routing before reaching it. So we can either move filtering
to prerouting to count non-routable packets as well or just let them
silently fall off.


Niko Kortström

On Wed, Sep 1, 2021 at 6:13 PM Kerin Millar <kfm@plushkava.net> wrote:
>
> On Wed, 1 Sep 2021 16:59:44 +0300
> Niko Kortström <niko.kortstrom@gmail.com> wrote:
>
> > Hi
> >
> > Sorry on we're making some changes and changing the names, on target
> > ip-filtering has been changed to ecpri-ip-filtering. We're wondering how do
> > the packets filtered not increase counters past the accept rule if they are
> > not accepted by it.
> >
> > # ip netns exec radions sysctl -a | grep '\.rp_filter'.
> > net.ipv4.conf.all.rp_filter = 2
> > net.ipv4.conf.default.rp_filter = 0
> > net.ipv4.conf.rfoe4.rp_filter = 0
> > net.ipv4.conf.rfoe4/295.rp_filter = 0
> >
> > No martians seem to be logged by the kernel.
>
> For them to be logged requires that net.ipv4.conf.*.log_martians be set to a value of 1, where * is either "all" or the link name in question.
>
> Also, you could try adding something like this:-
>
> chain prerouting {
>         type filter hook prerouting priority raw; policy accept;
>         ip daddr 10.0.0.0/8 meta nftrace set 1
> }
>
> In the case that the packet is being processed by Netfilter, you may then determine how it traverses your ruleset by executing "nft monitor trace".
>
> --
> Kerin Millar

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-09-01 16:31 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CADjU3LmddfsRShNVx-hArmivM=iUGvEFg28Gd90qyg7VRGqvbw@mail.gmail.com>
2021-09-01  7:40 ` Fwd: IP daddr filtering not working for non-routable address Niko Kortström
2021-09-01 10:06   ` Kerin Millar
     [not found]     ` <CADjU3LnN_uLqZ1LKJcjBCotv+OVJiL7v8xdsdt89_nxHOqHJjw@mail.gmail.com>
2021-09-01 11:24       ` Kerin Millar
2021-09-01 14:59         ` Niko Kortström
     [not found]         ` <CADjU3L=Q=rxK6Oy37SbN=ANXN6ig+rKdkZ_6iU+3j3AYkrY4sQ@mail.gmail.com>
2021-09-01 15:13           ` Kerin Millar
2021-09-01 16:31             ` Niko Kortström

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.