Re: Debian 12 - IPv4 blocked without fail2ban & co

[Romain]

I'm able to reproduce.

I can confirm that when this happens, it's the OVH server that fails to
send the response to my network.

35 9.862648672 MY_PUBLIC_IP_AT_HOME → 54.38.38.159 ICMP 78 Echo (ping)
request  id=0x4b30, seq=33150/32385, ttl=1
36 9.862704895 54.38.38.159 →  MY_PUBLIC_IP_AT_HOME  ICMP 106 Destination
unreachable (Port unreachable)

MTR from the OVH server to home:
Start: 2023-09-07T23:30:08+0200
HOST: rbx Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 54.38.38.252   0.0%100.6   0.5   0.3   0.7   0.1
  2.|-- 10.162.250.98  0.0%100.9   0.5   0.4   0.9   0.1
  3.|-- 10.72.52.320.0%100.5   0.5   0.4   0.7   0.1
  4.|-- 10.73.17.420.0%100.2   0.2   0.1   0.3   0.0
  5.|-- 10.95.64.152   0.0%101.1   1.2   1.1   1.5   0.1
  6.|-- 54.36.50.226   0.0%104.4   4.4   4.2   4.7   0.2
  7.|-- 10.200.2.730.0%10   78.0  11.6   4.1  78.0  23.4
  8.|-- ???   100.0100.0   0.0   0.0   0.0   0.0

Le jeu. 7 sept. 2023 à 14:12, zithro  a écrit :

> I'll write my answer here as well, as the OP posted the same posts on
> debian-french (also top-posting ...).
>
> Some ISPs or service providers may use private IPs (RFC1918) or even
> APIPA for their internal routers, to spare public IPs.
> CG-NAT (which uses APIPAs) especially may create some weird problems.
>
> I think it's just a coincidence that the provider uses 192.168.0.2
> internally and the OP host has the same address in its network.
>
>
> --
> ++
> zithro / Cyril
>
>

Re: raid10 access problem

[gene heskett]

On 9/7/23 13:28, Dan Ritter wrote:

module(load="imuxsock" SysSock.Name="/run/systemd/journal/syslog" ) # provides 
support for local system logging

There was a simpler line there, I commented it out.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: raid10 access problem

[gene heskett]

On 9/7/23 13:28, Dan Ritter wrote:

gene heskett wrote:

On 9/7/23 10:34, Dan Ritter wrote:

gene heskett wrote:

I thought, when I installed bullseye on this box, that a raid is what I
needed for a /home partition, and indeed under bullseye it worked
flawlessly.  Since my surprise install of bookworm, cause by an update to
bullseye wiping out my user pw, so I went to another machine and downloaded
the netinstall.

This raid is 4, 1T samsung SSD's, software raid.


I'm going to assume you're using the kernel's md system. What
does

cat /proc/mdstat

say?

-dsr-
.

gene@coyote:/home/nut$ cat /proc/mdstat
Personalities : [raid10] [linear] [multipath] [raid0] [raid1] [raid6]
[raid5] [raid4]
md0 : active raid10 sdg1[1] sdf1[0] sdi1[3] sdh1[2]
   1842937856 blocks super 1.2 512K chunks 2 near-copies [4/4] []
   bitmap: 6/14 pages [24KB], 65536KB chunk

md1 : active (auto-read-only) raid10 sdi2[3] sdg2[1] sdf2[0] sdh2[2]
   62879744 blocks super 1.2 512K chunks 2 near-copies [4/4] []
 resync=PENDING

md2 : active (auto-read-only) raid10 sdf3[0] sdi3[3] sdg3[1] sdh3[2]
   3166208 blocks super 1.2 512K chunks 2 offset-copies [4/4] []

unused devices: 
neither md1, nor md2 is actually mounted.



That looks fine.

Let's get you logging things again.

apt install rsyslog

Then, in  /etc/systemd/system/syslog.service  add

Requires=syslog.socket


under which [heading]?

and in  /etc/rsyslog.conf  add

module(load="imuxsock" SysSock.Name="/run/systemd/journal/syslog" ) # provides 
support for local system logging

and now systemd will copy logs to rsyslogd, where they can be
sent to disk in the old familiar way.

-dsr-
.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: raid10 access problem

[gene heskett]

On 9/7/23 10:34, Dan Ritter wrote:

gene heskett wrote:

I thought, when I installed bullseye on this box, that a raid is what I
needed for a /home partition, and indeed under bullseye it worked
flawlessly.  Since my surprise install of bookworm, cause by an update to
bullseye wiping out my user pw, so I went to another machine and downloaded
the netinstall.

This raid is 4, 1T samsung SSD's, software raid.


I'm going to assume you're using the kernel's md system. What
does

cat /proc/mdstat

say?

-dsr-
.

gene@coyote:/home/nut$ cat /proc/mdstat
Personalities : [raid10] [linear] [multipath] [raid0] [raid1] [raid6] 
[raid5] [raid4]

md0 : active raid10 sdg1[1] sdf1[0] sdi1[3] sdh1[2]
  1842937856 blocks super 1.2 512K chunks 2 near-copies [4/4] []
  bitmap: 6/14 pages [24KB], 65536KB chunk

md1 : active (auto-read-only) raid10 sdi2[3] sdg2[1] sdf2[0] sdh2[2]
  62879744 blocks super 1.2 512K chunks 2 near-copies [4/4] []
resync=PENDING

md2 : active (auto-read-only) raid10 sdf3[0] sdi3[3] sdg3[1] sdh3[2]
  3166208 blocks super 1.2 512K chunks 2 offset-copies [4/4] []

unused devices: 
neither md1, nor md2 is actually mounted.

Thank you DSR.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

raid10 access problem

[gene heskett]

Greetings all;

I thought, when I installed bullseye on this box, that a raid is what I 
needed for a /home partition, and indeed under bullseye it worked 
flawlessly.  Since my surprise install of bookworm, cause by an update 
to bullseye wiping out my user pw, so I went to another machine and 
downloaded the netinstall.


This raid is 4, 1T samsung SSD's, software raid.

Now, random programs that need to write something to this raid, may open 
instantly a file requestor to select where they put the data, or they 
may just put an icon on he toolbar, which may finish opening the 
requester instantly, or far more likely delay that for 2 minutes or 
more. 30 seconds seems to be the minumum delay. I have fsck'd the raid10 
several times w/o gaining any knowledge. You've buried the logs, and 
what I can get out of journlctl does not contain any useful info as to 
why its so slow.


How do I generate some info that might point me at a solution?

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: bug report question

[Dan Purgert]

On Sep 07, 2023, duh_gently...@simplelogin.com wrote:
> Thank you for your advice!

No problem.

> 
> lspci says:
> 00:01.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models
> 00h-0fh) PCIe GPP Bridge

Okay so it's the root PCI bridge on the motherboard.  Are there any
BIOS/UEFI updates available?

> 
> The only 2 PCIe devices I have are my video card and my m.2 drive. I have
> had different kernel versions as I have had this problem for at least 6
> months (debian testing)... so I can't really say when it all started.

What kernel are you running right now?


-- 
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860


signature.asc
Description: PGP signature

Re: pppoe ipv6 PD

[basti]

On 07.09.23 13:56, Anssi Saari wrote:

basti  writes:


My changes where attached in my last mail. Did you seen it?
Have a look at the mailing archive:

https://lists.debian.org/debian-user/2023/09/msg00157.html


No, you posted only your new versions so I can't know what you
actually changed. You posted originally that you have:

[Network]
IPv6SendRA=yes
DHCPv6PrefixDelegation=yes

On the LAN side. And now you have:

[Match]
Name=enp1s0f0

[Network]
IPv6SendRA=yes
IPv6AcceptRA=no
DHCPPrefixDelegation=yes

[IPv6SendRA]
EmitDNS=no
EmitDomains=no

So was it IPv6AcceptRA=no that fixed it? Or something else?

I only have post the relevant options, so you need all of them, 
depending on you environment. I don't know if you want to use the DNS 
Server of your ISP.


For more info's about the options see 'man systemd.network'

You also need to accept RA on the ppp interface and start a dhcpv6 
client there, if your ISP distribute IPv6 via dhcp.

Re: bug report question

[duh_gently889]

Thank you for your advice!

lspci says:
00:01.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-0fh) PCIe GPP Bridge


The only 2 PCIe devices I have are my video card and my m.2 drive. I 
have had different kernel versions as I have had this problem for at 
least 6 months (debian testing)... so I can't really say when it all 
started.


But for me, at least a half-solution would be to stop these errors being 
logged, so that I can shut down the computer properly. When the root 
file system is full, many programs stop working, and even after a 
reboot, the user interface will not start.


On 07/09/2023 12.24, Dan Purgert - dan at djph.net wrote:

On Sep 07, 2023, duh_gently...@simplelogin.com wrote:

Hello,

I'd like to submit a bug, but I'm not quite sure which package it
should be.
I could not find anything similar in the bugtracker.

The problem occurs every 10-20 times. After the system has been suspended
and then resumed, the following message is written to kern.log and syslog:

2023-09-07T09:43:21.264297+02:00 host kernel: [527584.040221] pcieport
:00:01.3: PME: Spurious native interrupt!
[...]

I accept that the message may indicate a valid problem, but having so many
log messages is not OK either. Currently, when this happens, I am
forced to manually delete the log file and reboot.

At first glance, it seems to be hardware related. What device is plugged
into that PCIe slot (or is it the PCIe Root)?


In no particular order:

   - Check for a BIOS/UEFI update
   - Check with an older kernel
   - Check for an updated kernel module / driver
   - Reboot and revert to the previously working kernel revision / patch

Re: Debian 12 - IPv4 blocked without fail2ban & co

[zithro]

I'll write my answer here as well, as the OP posted the same posts on 
debian-french (also top-posting ...).


Some ISPs or service providers may use private IPs (RFC1918) or even 
APIPA for their internal routers, to spare public IPs.

CG-NAT (which uses APIPAs) especially may create some weird problems.

I think it's just a coincidence that the provider uses 192.168.0.2 
internally and the OP host has the same address in its network.



--
++
zithro / Cyril

Re: pppoe ipv6 PD

[Anssi Saari]

basti  writes:

> My changes where attached in my last mail. Did you seen it?
> Have a look at the mailing archive:
>
> https://lists.debian.org/debian-user/2023/09/msg00157.html

No, you posted only your new versions so I can't know what you
actually changed. You posted originally that you have:

[Network]
IPv6SendRA=yes
DHCPv6PrefixDelegation=yes

On the LAN side. And now you have:

[Match]
Name=enp1s0f0

[Network]
IPv6SendRA=yes
IPv6AcceptRA=no
DHCPPrefixDelegation=yes

[IPv6SendRA]
EmitDNS=no
EmitDomains=no

So was it IPv6AcceptRA=no that fixed it? Or something else? 

Re: Debian 12 - IPv4 blocked without fail2ban & co

[Max Nikulin]

On 07/09/2023 17:32, Andy Smith wrote:

On Thu, Sep 07, 2023 at 12:20:18PM +0200, Romain wrote:

With -n (sometimes it stops at hop 7, sometimes 9):
└─# mtr -nr 54.38.38.159 -4
Start: 2023-09-07T08:17:12+
HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst StDev

 

   9.|-- 192.168.0.2   90.0%10  3461. 3461. 3461. 3461.   0.0

To me this suggests that the ICMP Time Exceeded packet is arriving
with source address 192.168.0.2, which I think means it is being
sent to you by your own ISP.


I guess, these packets are generated by localhost = rpi4.home = 
192.168.0.2. At first I did not noticed excessively large time in the 
last line.


Concerning question related to .home, perhaps it is just /etc/hosts with
192.168.0.1 livebox.home
192.168.0.2 rpi4.home

I do not suspect some peculiarities in local configuration anymore. 
tcpdump on the server may shed some light if packets from localhost 
arrive to it.

Re: bug report question

[Dan Purgert]

On Sep 07, 2023, duh_gently...@simplelogin.com wrote:
> Hello,
> 
> I'd like to submit a bug, but I'm not quite sure which package it
> should be.
> I could not find anything similar in the bugtracker.
> 
> The problem occurs every 10-20 times. After the system has been suspended
> and then resumed, the following message is written to kern.log and syslog:
> 
> 2023-09-07T09:43:21.264297+02:00 host kernel: [527584.040221] pcieport
> :00:01.3: PME: Spurious native interrupt!
> [...]
> 
> I accept that the message may indicate a valid problem, but having so many
> log messages is not OK either. Currently, when this happens, I am
> forced to manually delete the log file and reboot.

At first glance, it seems to be hardware related. What device is plugged
into that PCIe slot (or is it the PCIe Root)?


In no particular order:

  - Check for a BIOS/UEFI update
  - Check with an older kernel
  - Check for an updated kernel module / driver
  - Reboot and revert to the previously working kernel revision / patch



-- 
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860


signature.asc
Description: PGP signature

Re: Debian 12 - IPv4 blocked without fail2ban & co

[Andy Smith]

Hello,

On Thu, Sep 07, 2023 at 12:20:18PM +0200, Romain wrote:
> With -n (sometimes it stops at hop 7, sometimes 9):
> └─# mtr -nr 54.38.38.159 -4
> Start: 2023-09-07T08:17:12+
> HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst StDev
>   1.|-- 192.168.0.10.0%101.1   0.9   0.5   1.3   0.3
>   2.|-- 80.10.239.90.0%103.2   3.3   2.3   5.3   0.9
>   3.|-- 193.253.80.138 0.0%104.5   4.0   2.2   6.0   1.2
>   4.|-- 193.252.98.94  0.0%103.4   4.3   3.1  12.2   2.8
>   5.|-- 193.252.98.101 0.0%103.5   3.4   2.9   3.6   0.2
>   6.|-- 91.121.131.193 0.0%104.0  12.4   3.7  82.6  24.7
>   7.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
>   8.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
>   9.|-- 192.168.0.2   90.0%10  3461. 3461. 3461. 3461.   0.0

To me this suggests that the ICMP Time Exceeded packet is arriving
with source address 192.168.0.2, which I think means it is being
sent to you by your own ISP.

The way mtr works is to send an ICMP Echo Request packet to
54.38.38.159 with TTl set to 1 and see where the ICMP Time Exceeded
reply comes from, in this case 192.168.0.1. So it knows 192.168.0.1
is first hope. Then it does it again with TTL=2 and gets a reply
from 80.10.239.9. And so on.

So here when it does TTL=9 it gets a reply back from 192.168.0.2.

While it is possible that a string of providers are somehow routing
a packet that says it is from 192.168.0.2 back to you, really it is
most likely that this packet came from your own network or the thing
it is immediately connected to.

You may want to confirm with tcpdump that you receive a packet in on
your internet interface with source address 192.168.0.2.

In summary, I don't think it's OVH. I think it is your ISP or your
home router.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Debian 12 - IPv4 blocked without fail2ban & co

[Romain]

No, I'm using the DNS server included in my ISP modem, in which I can only
select the last digits. It's impossible that an internal device has
received a public IP address in the DNS zone (or it's not something I've
done).

With -n (sometimes it stops at hop 7, sometimes 9):
└─# mtr -nr 54.38.38.159 -4
Start: 2023-09-07T08:17:12+
HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.10.0%101.1   0.9   0.5   1.3   0.3
  2.|-- 80.10.239.90.0%103.2   3.3   2.3   5.3   0.9
  3.|-- 193.253.80.138 0.0%104.5   4.0   2.2   6.0   1.2
  4.|-- 193.252.98.94  0.0%103.4   4.3   3.1  12.2   2.8
  5.|-- 193.252.98.101 0.0%103.5   3.4   2.9   3.6   0.2
  6.|-- 91.121.131.193 0.0%104.0  12.4   3.7  82.6  24.7
  7.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
  8.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
  9.|-- 192.168.0.2   90.0%10  3461. 3461. 3461. 3461.   0.0

Le jeu. 7 sept. 2023 à 12:17, Max Nikulin  a écrit :

> On 07/09/2023 14:31, Romain wrote:
> >   12.|-- rpi4.home 90.0%10  7955. 7955. 7955. 7955.
> >0.0
>
> May it happen that you associated a local device with the IP of your
> remote server? Check configuration of the .home DNS zone. Try to add -n
> option to suppress DNS lookup and compare results.
>
>

Re: Debian 12 - IPv4 blocked without fail2ban & co

[Max Nikulin]

On 07/09/2023 14:31, Romain wrote:
  12.|-- rpi4.home                 90.0%    10  7955. 7955. 7955. 7955. 
   0.0


May it happen that you associated a local device with the IP of your 
remote server? Check configuration of the .home DNS zone. Try to add -n 
option to suppress DNS lookup and compare results.

bug report question

[duh_gently889]

Hello,

I'd like to submit a bug, but I'm not quite sure which package it should 
be. I could not find anything similar in the bugtracker.


The problem occurs every 10-20 times. After the system has been 
suspended and then resumed, the following message is written to kern.log 
and syslog:


2023-09-07T09:43:21.264297+02:00 host kernel: [527584.040221] pcieport 
:00:01.3: PME: Spurious native interrupt!
2023-09-07T09:43:21.264297+02:00 host kernel: [527584.040225] pcieport 
:00:01.3: PME: Spurious native interrupt!
2023-09-07T09:43:21.264298+02:00 host kernel: [527584.040229] pcieport 
:00:01.3: PME: Spurious native interrupt!
2023-09-07T09:43:21.264298+02:00 host kernel: [527584.040233] pcieport 
:00:01.3: PME: Spurious native interrupt!
2023-09-07T09:43:21.264299+02:00 host kernel: [527584.040237] pcieport 
:00:01.3: PME: Spurious native interrupt!
2023-09-07T09:43:21.264299+02:00 host kernel: [527584.040241] pcieport 
:00:01.3: PME: Spurious native interrupt!
2023-09-07T09:43:21.264300+02:00 host kernel: [527584.040244] pcieport 
:00:01.3: PME: Spurious native interrupt!
2023-09-07T09:43:21.264301+02:00 host kernel: [527584.040248] pcieport 
:00:01.3: PME: Spurious native interrupt!
2023-09-07T09:43:21.264301+02:00 host kernel: [527584.040252] pcieport 
:00:01.3: PME: Spurious native interrupt!


There are so many of them that within 10 minutes the log files are 
several GiB in size, filling the root filesystem and rendering the OS 
unusable.


I accept that the message may indicate a valid problem, but having so 
many log messages is not OK either. Currently, when this happens, I am 
forced to manually delete the log file and reboot.


Best regards,
Peter

Re: pppoe ipv6 PD

[basti]

On 07.09.23 10:27, Anssi Saari wrote:

basti  writes:


Am 06.09.23 um 09:37 schrieb Marco:

Am 06.09.2023 09:24 schrieb Anssi Saari:


That should be enough but I don't really know how pppoe works, I've
only used IPv6 with tunneling, 6rd and 6in4 with the late route48.org.

With PPP IPv6CP (RFC 2472 is being used.
It negotiates a 64 bit interface identifier to create the link-local
address.
The rest is being done with router advertisement and optionally with
DHCPv6.



I get it working.


What did you change to make it work though?



My changes where attached in my last mail. Did you seen it?
Have a look at the mailing archive:

https://lists.debian.org/debian-user/2023/09/msg00157.html

Re: Debian 12 - IPv4 blocked without fail2ban & co

[Romain]

I can reproduce with OVH IPs, but not with Scaleway IPs. I smell filtering
on the OVH side.

Le jeu. 7 sept. 2023 à 09:48, Paul van der Vlis  a
écrit :

> Op 06-09-2023 om 15:40 schreef Romain:
> > Next time it happens I'll run more tests from the server to my home.
> > I'm wondering if my modem at home could not be the culprit. I'm prepared
> > for more tests here too.
>
> If you have switches at home, those could be the problem too.
>
> You could let log iptables, in this way you can see if the packets reach
> the machine.
>
> With regards,
> Paul
>
>
>
>
> --
> Paul van der Vlis Linux systeembeheer Groningen
> https://vandervlis.nl
>
>

Re: pppoe ipv6 PD

[Anssi Saari]

basti  writes:

> Am 06.09.23 um 09:37 schrieb Marco:
>> Am 06.09.2023 09:24 schrieb Anssi Saari:
>> 
>>> That should be enough but I don't really know how pppoe works, I've
>>> only used IPv6 with tunneling, 6rd and 6in4 with the late route48.org.
>> With PPP IPv6CP (RFC 2472 is being used.
>> It negotiates a 64 bit interface identifier to create the link-local
>> address.
>> The rest is being done with router advertisement and optionally with
>> DHCPv6.
>> 
>
> I get it working.

What did you change to make it work though?

Re: Debian 12 - IPv4 blocked without fail2ban & co

[Paul van der Vlis]

Op 06-09-2023 om 15:40 schreef Romain:

Next time it happens I'll run more tests from the server to my home.
I'm wondering if my modem at home could not be the culprit. I'm prepared 
for more tests here too.


If you have switches at home, those could be the problem too.

You could let log iptables, in this way you can see if the packets reach 
the machine.


With regards,
Paul




--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl

Re: Debian 12 - IPv4 blocked without fail2ban & co

[Romain]

It happened again last night, but I wasn't able to investigate before I
woke up, and for the moment it's not blocking anymore.
Out of curiosity, I'm doing a regular MTR, and I've had a strange thing
happen.

A normal one (rpi4 at home to OVH):
└─# mtr -r 54.38.38.159 -4
Start: 2023-09-07T07:14:15+
HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- livebox.home   0.0%101.0   0.9   0.7   1.1   0.1
  2.|-- 80.10.239.90.0%103.0   2.9   2.7   3.5   0.3
  3.|-- ae102-0.ncidf103.rbci.ora  0.0%103.3   3.4   2.2   6.3   1.1
  4.|-- ae51-0.nridf101.rbci.oran  0.0%103.2   3.4   3.1   3.6   0.2
  5.|-- ae41-0.noidf001.rbci.oran  0.0%103.5   3.7   3.2   5.4   0.6
  6.|-- be102.par-th2-pb1-nc5.fr.  0.0%10   25.9   9.6   3.7  31.7  10.5
  7.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
  8.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
  9.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 10.|-- be103.rbx-g4-nc5.fr.eu 0.0%108.1   9.0   7.2  20.9   4.2
 11.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 12.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 13.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 14.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 15.|-- mail.borezo.info   0.0%106.9   7.2   6.7   7.9   0.4

The same one a few minutes later (not normal):
└─# mtr -r 54.38.38.159 -4
Start: 2023-09-07T07:24:27+
HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- livebox.home   0.0%100.9   1.1   0.7   2.8   0.6
  2.|-- 80.10.239.90.0%102.8   3.0   2.7   4.4   0.5
  3.|-- ae102-0.ncidf103.rbci.ora  0.0%10   37.3   6.8   2.7  37.3  10.7
  4.|-- ae51-0.nridf101.rbci.oran  0.0%103.5   3.5   3.1   4.6   0.4
  5.|-- ae41-0.noidf001.rbci.oran  0.0%103.3   3.9   3.2   8.4   1.6
  6.|-- be102.par-th2-pb1-nc5.fr.  0.0%103.7  14.0   3.7  44.1  15.0
  7.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
  8.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
  9.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 10.|-- be103.rbx-g4-nc5.fr.eu 0.0%107.5   8.4   7.1  12.1   1.7
 11.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 12.|-- rpi4.home 90.0%10  7955. 7955. 7955. 7955.   0.0

Le mer. 6 sept. 2023 à 08:39, Romain  a écrit :

> Hello everyone,
>
> I recently reinstalled a dedicated server (with OVH, in case that helps
> with diagnosis), transitioning from Debian 11 to Debian 12.
>
> Since then, I have been experiencing regular and progressive IPv4 blocking
> at my home. Access via IPv6 or from another IPv4 (including from the same
> provider) is working.
>
> Here's an example from last night after a server reboot the previous
> evening:
> 01:43-02:13 (30 minutes)
> 02:26-03:26 (1 hour)
> 03:28-05:28 (2 hours)
> 05:55-? (still blocked at the time of writing)
>
> Issues:
> - The OVH Debian 12 template for dedicated servers doesn't come with any
> pre-installed blocking tools (e.g., no fail2ban).
> - I haven't added any such tools since installing the server, only Apache
> (with mod_security), PHP, and MariaDB.
> - From my home IP address last night, the only generated requests were
> from my Uptime Kuma probe, which includes a ping every minute and a curl
> request to a URL that consistently returns HTTP 200 (except when the IP is
> blocked, of course).
>
> When my IP is blocked, curl returns a "Connection refused," and ping
> returns "Destination Port Unreachable."
>
> I couldn't find any mentions of my IPv4 address in the server logs. MTR
> (-4) doesn't report any issues reaching the server. OVH has confirmed that
> it's not an issue with their network equipment, and a rescue mode restart
> allows me to regain ping access.
>
> Do you have any ideas about what might be causing this on a nearly
> pristine Debian 12 installation? I've been pulling my hair out for a few
> days now...
>
> Thanks!
>
> Romain
>
>
>
>
>