As already reported, when it's blocked, all traffic is blocked on IPv4,
including SSH & HTTP.
Le sam. 9 sept. 2023 à 06:42, Timothy M Butterworth <
timothy.m.butterwo...@gmail.com> a écrit :
>
>
> On Fri, Sep 8, 2023 at 10:52 PM Max Nikulin wrote:
>
>> On 08/09/2023 04:39, Romain wrote:
>> > I
On Fri, Sep 8, 2023 at 10:52 PM Max Nikulin wrote:
> On 08/09/2023 04:39, Romain wrote:
> > 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
On 08/09/2023 04:39, Romain wrote:
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 →
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
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
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
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.1
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
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
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
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
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:
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.
But yes I'm sure I don't have any rules on the server:
# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source
On Wed, Sep 06, 2023 at 10:59:29AM +0200, Romain wrote:
> >
> > So when this is happening mtr works but http, ssh and ping don't?
>
> Yes
I think there is definitely a firewall involved somewhere as that is
quite complicated selective blocking: it's allowing back the ICMP
Time Exceeded packets
>
> So when this is happening mtr works but http, ssh and ping don't?
Yes
If you run tcpdump on the server, do your http/ssh packets even
> reach it?
I wasn't seeing any request coming from my IP last time I checked. I'll
re-check.
If you do tcptraceroute on port 22/80/443 from your home, how
Hi,
On Wed, Sep 06, 2023 at 08:39:55AM +0200, Romain wrote:
> 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
No but's this is what I plan to do next time :)
Le mer. 6 sept. 2023 à 10:41, Michel Verdier a écrit :
> On 2023-09-06, Romain wrote:
>
> > I couldn't find any mentions of my IPv4 address in the server logs. MTR
> > (-4) doesn't report any issues reaching the server.
>
> Did you run mtr from
On 2023-09-06, Romain wrote:
> I couldn't find any mentions of my IPv4 address in the server logs. MTR
> (-4) doesn't report any issues reaching the server.
Did you run mtr from the both sides ?
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
19 matches
Mail list logo
