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
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]
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
On Fri, Jan 12, 2024 at 05:26:57PM +, 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
On 12 Jan 2024 16:19 +0100, from r...@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
On Fri, Jan 12, 2024 at 03:52:46PM +, 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"
On Fri, Jan 12, 2024 at 03:52:46PM +, 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
> you
k.
> 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
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
NoSpam a écrit :
>
> Le 03/07/2023 à 15:12, BERTRAND Joël a écrit :
>> NoSpam a écrit :
>>> Ils n'arrivent jamais plus loin que mangle INPUT qui est avant la table
>>> nat et filter
>> D'accord. Mais dans ce cas, pourquoi sngrep les intercepte ?
> Tout comme iptables et tcpdump, les paquets
Le 03/07/2023 à 15:12, BERTRAND Joël a écrit :
NoSpam a écrit :
Ils n'arrivent jamais plus loin que mangle INPUT qui est avant la table
nat et filter
D'accord. Mais dans ce cas, pourquoi sngrep les intercepte ?
Tout comme iptables et tcpdump, les paquets sont capturés dès leur
NoSpam a écrit :
> Ils n'arrivent jamais plus loin que mangle INPUT qui est avant la table
> nat et filter
D'accord. Mais dans ce cas, pourquoi sngrep les intercepte ?
JB
le firewall.
J'obtiens ceci :
2023-07-03T14:37:45.868470+02:00 rayleigh kernel: [705875.038988] TRACE:
raw:PREROUTING:policy:2 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209
DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF
PROTO=UDP SPT=5256 DPT=5060
Thomas Trupel a écrit :
> C'est un comportement normal à mes yeux.
>
> L'ajout d'une règle avec la target TRACE devrait te confirmer que les
> paquets sont bloqués par le firewall.
J'obtiens ceci :
2023-07-03T14:37:45.868470+02:00 rayleigh kernel: [705875.038988] TRACE:
raw:PREROUT
Thomas Trupel a écrit :
> C'est un comportement normal à mes yeux.
>
> L'ajout d'une règle avec la target TRACE devrait te confirmer que les
> paquets sont bloqués par le firewall.
Dans le cas de SIP, ils sont tout de même récupérés par sngrep :
[ ] 359 INVITE
C'est un comportement normal à mes yeux.
L'ajout d'une règle avec la target TRACE devrait te confirmer que les
paquets sont bloqués par le firewall.
|Cordialement, Thomas|
On 7/3/23 14:14, BERTRAND Joël wrote:
C'est même pire que ça !
Si je fais un nmap depuis l'extérieur sur le serveur
C'est même pire que ça !
Si je fais un nmap depuis l'extérieur sur le serveur en question,
j'obtiens bien :
legendre# nmap 192.168.15.18
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-03 14:09 CEST
Nmap scan report for 192.168.15.18
Host is up (0.00078s latency).
Not shown: 987 filtered tcp
Joël wrote:
Bonjour à tous,
Je suis en train de configurer (péniblement) un serveur asterisk qui
est dans un DMZ. Tout le flux entrant sur l'IP publique est naté vers ce
serveur, protégé par un firewall iptables et fail2ban. Il s'agit
d'iptables et non d'iptables-legacy
Bonjour à tous,
Je suis en train de configurer (péniblement) un serveur asterisk qui
est dans un DMZ. Tout le flux entrant sur l'IP publique est naté vers ce
serveur, protégé par un firewall iptables et fail2ban. Il s'agit
d'iptables et non d'iptables-legacy.
Cette
Já fiz, mas faz muito tempo atrás. Com iptables.
./helio
On Thu, Nov 17, 2022, 13:32 Marcelo wrote:
> Bom dia pessoal,
>
> Alguém utiliza o Debian no modo Bridge + firewall?
>
> Estou com algumas dúvidas para habilitar o firewall...
>
> Obrigado!
>
Bom dia pessoal,
Alguém utiliza o Debian no modo Bridge + firewall?
Estou com algumas dúvidas para habilitar o firewall...
Obrigado!
Subject: I have finally figured out how to export Private Key from
Fortigate firewall and successfully install Godaddy Wildcard SSL
certificate in UniFi Cloud Key Gen 2 Plus Network Controller
Good day from Singapore,
Author: Mr. Turritopsis Dohrnii Teo En Ming
Country: Singapore
Date: 26 Oct
On 2/06/22 05:26, Joe wrote:
On Tue, 31 May 2022 03:17:52 +0100
mick crane wrote:
regarding firewall discussion I'm uncertain how firewalls are
supposed to work.
I think the idea is that nothing is accepted unless it is in response
to a request.
What's to stop some spurious instructions being
On 2022-06-01 18:26, Joe wrote:
On Tue, 31 May 2022 03:17:52 +0100
mick crane wrote:
regarding firewall discussion I'm uncertain how firewalls are
supposed to work.
I think the idea is that nothing is accepted unless it is in response
to a request.
What's to stop some spurious instructions
On Wed, 1 Jun 2022 15:02:10 -0400
rhkra...@gmail.com wrote:
> > mick crane wrote:
> > > regarding firewall discussion I'm uncertain how firewalls are
> > > supposed to work.
> > > I think the idea is that nothing is accepted unless it is in
> > > r
> mick crane wrote:
> > regarding firewall discussion I'm uncertain how firewalls are
> > supposed to work.
> > I think the idea is that nothing is accepted unless it is in response
> > to a request.
> > What's to stop some spurious instructions being sent i
On Tue, 31 May 2022 03:17:52 +0100
mick crane wrote:
> regarding firewall discussion I'm uncertain how firewalls are
> supposed to work.
> I think the idea is that nothing is accepted unless it is in response
> to a request.
> What's to stop some spurious instructions being s
On Wed, Jun 1, 2022 at 11:21 john doe wrote:
> when does it actually start operating? Does it do so then, or does it take
>
> a reboot?
>
Apparently, if you 'enable' 'ufw', it will start and be enabled at boot.
Good, thanks.
According to (1), ufw should work with nftables, I did not follow
ready for use by a customer, yours truly. It is the
same
server I messed up the firewall with and locked myself out of. The OS
has
been reinstalled and is ready for me to use again.
On that note, for my next try with the server, I will definitely use UFW
with the legacy uptables
er ready for use by a customer, yours truly. It is the
> same
> >> server I messed up the firewall with and locked myself out of. The OS
> has
> >> been reinstalled and is ready for me to use again.
On that note, for my next try with the server, I will definitely use UFW
with t
On 2022-05-31 12:21, IL Ka wrote:
What's to stop some spurious instructions being sent in response to
genuine request?
Packets do not contain instructions, only data. If your TCP/IP
implementation doesn't have vulnerabilities any packet shouldn't be a
problem.
Firewall prevents technically
spurious instructions being sent in response to
> genuine request?
Packets do not contain instructions, only data. If your TCP/IP
implementation doesn't have vulnerabilities any packet shouldn't be a
problem.
Firewall prevents technically legal packets from reaching software that
shouldn't be acce
On 31/5/22 10:17 am, mick crane wrote:
regarding firewall discussion I'm uncertain how firewalls are supposed
to work.
I think the idea is that nothing is accepted unless it is in response
to a request.
What's to stop some spurious instructions being sent in response to
genuine request
mick crane wrote:
> regarding firewall discussion I'm uncertain how firewalls
> are supposed to work. I think the idea is that nothing is
> accepted unless it is in response to a request. What's to
> stop some spurious instructions being sent in response to
> genuine request?
Fir
regarding firewall discussion I'm uncertain how firewalls are supposed
to work.
I think the idea is that nothing is accepted unless it is in response to
a request.
What's to stop some spurious instructions being sent in response to
genuine request?
regards
mick
On 5/30/22 09:41, Greg Wooledge wrote:
> On Mon, May 30, 2022 at 07:13:54AM -0500, Tom Browder wrote:
>> No worries. All those responses about the subject IP now are the norm for a
>> bare-iron server ready for use by a customer, yours truly. It is the same
>> server I m
On Mon, May 30, 2022 at 1:24 PM Tom Browder wrote:
> On Mon, May 30, 2022 at 09:03 IL Ka wrote:
>
>> IMHO: It is better to have a firewall and block (policy -- drop) INPUT
>> and FORWARD by default.
>> And open only ports that must be opened.
>> This will hel
On Mon, May 30, 2022 at 09:03 IL Ka wrote:
> IMHO: It is better to have a firewall and block (policy -- drop) INPUT and
> FORWARD by default.
> And open only ports that must be opened.
> This will help if you install some software that listens for 0.0.0.0 by
> accident
>
On Mon, May 30, 2022 at 08:42 Greg Wooledge wrote:
..
> Unless this machine is more than just a web server...?
It does serve other purposes.
IMHO: It is better to have a firewall and block (policy -- drop) INPUT and
FORWARD by default.
And open only ports that must be opened.
This will help if you install some software that listens for 0.0.0.0 by
accident
On Mon, May 30, 2022 at 4:42 PM Greg Wooledge wrote:
> On Mon, May 30, 2
On Mon, May 30, 2022 at 07:13:54AM -0500, Tom Browder wrote:
> No worries. All those responses about the subject IP now are the norm for a
> bare-iron server ready for use by a customer, yours truly. It is the same
> server I messed up the firewall with and locked myself out of. The OS h
urs truly. It is the same
server I messed up the firewall with and locked myself out of. The OS has
been reinstalled and is ready for me to use again.
If all is set as expected, I should be able to get http and https working
on it.
And I will certainly try to take care of most of the security concerns
expre
On 2022-05-29, Greg Wooledge wrote:
>
> Second, I cannot ping this IP address, nor can I telnet to port 80 of it.
> (Nor port 22.)
>
That's strange; I can ping it (I'm not in Kansas anymore):
curty@einstein:~$ ping 69.30.225.10
PING 69.30.225.10 (69.30.225.10) 56(84) bytes of data.
64 bytes
On 5/30/2022 12:26 AM, Tom Browder wrote:
On Sun, May 29, 2022 at 15:55 Greg Wooledge wrote:
...
Thanks, Greg. It looks like my server was blocked from ports 80 and 443
upstream from it (as you and others suspected), so I asked my provider to
reinstall the OS and ensure it has public access to
> Maybe I should remove all firewall progs and start from zero.
I would suggest you install Shorewall. it is not the pain in the arse that's
been the theme of this thread so far.
On Sun, May 29, 2022 at 8:13 PM Greg Wooledge wrote:
> On Sun, May 29, 2022 at 11:50:44PM +, Lee wrote:
> > On 5/29/22, Greg Wooledge wrote:
> > > Second, I cannot ping this IP address, nor can I telnet to port 80 of
> it.
> >
> > For whatever it's worth..
> >
> > Pinging 69.30.225.10 with
>
>
> ssh gives me a login prompt
>
>
Btw, I highly recommend:
* Block SSH access from any IP except one you are going to use to manage
this server
* If you have dynamic IP, you can add all your ISP network, or, at least,
your country: (list can be downloaded here
On Sun, May 29, 2022 at 11:50:44PM +, Lee wrote:
> On 5/29/22, Greg Wooledge wrote:
> > Second, I cannot ping this IP address, nor can I telnet to port 80 of it.
>
> For whatever it's worth..
>
> Pinging 69.30.225.10 with 32 bytes of data:
> Reply from 69.30.225.10: bytes=32 time=43ms
On 5/29/22, Greg Wooledge wrote:
> On Sun, May 29, 2022 at 03:39:05PM -0500, Tom Browder wrote:
>> I have not intentionally hidden anything, Greg--I just never saw the need
>> for
>> mentioning it given the dialogue--x.y.z.w is just shorthand. If you
>> must know the exact IP address, it is
On Sun, May 29, 2022 at 15:55 Greg Wooledge wrote:
...
Thanks, Greg. It looks like my server was blocked from ports 80 and 443
upstream from it (as you and others suspected), so I asked my provider to
reinstall the OS and ensure it has public access to ports 80 and 443.
Best regards,
-Tom
t's a huge red flag pointing to a
firewall that filters incoming connections based on source IP. Such
a firewall could be on the host itself, or on a router which protects
the host.
If you can't do any of those things, then we don't get as much information
out of it. It could simply be the wrong IP addr
On Sun, May 29, 2022 at 2:21 PM Greg Wooledge wrote:
>
> > > > btw, are you able to ping server?
> > >
> > > Yes.
> >
> > It is always better to show the command and the output instead of saying
> > yes/no! :)
>
> Except it should be abundantly clear by now that you're dealing with
> someone who
> > > btw, are you able to ping server?
> >
> > Yes.
>
> It is always better to show the command and the output instead of saying
> yes/no! :)
Except it should be abundantly clear by now that you're dealing with
someone who believes that they must hide every single detail from
the ones who
>
>
> I must say, I can not realy understand how you can ping and not
> telnet/access your web server.
>
>
Some router between OP and his server has something like
-I FORWARD -j REJECT --reject-with icmp-host-unreachable
On 5/29/2022 7:20 PM, Tom Browder wrote:
On Sun, May 29, 2022 at 11:39 IL Ka wrote:
btw, are you able to ping server?
Yes.
It is always better to show the command and the output instead of saying
yes/no! :)
I must say, I can not realy understand how you can ping and not
telnet/access
On Sun, May 29, 2022 at 11:39 IL Ka wrote:
> btw, are you able to ping server?
>
Yes.
st from the outside with the public IP and got no good response:
>
> $ telnet x.y.z.w 80
> Trying x.y.z.w...
> telnet: Unable to connect to remote host: No route to host
I may be off, but I think a firewall shouldn't do that [1]. It can
lead to a "connection refused&q
btw, are you able to ping server?
On Sun, May 29, 2022 at 7:26 PM Tom Browder wrote:
> On Sun, May 29, 2022 at 10:33 AM IL Ka wrote:
> >
> >
> >> When running those, I'm told neither the arptablrs nor the ebtables are
> registered (not installed). Should I install them?
> >
> > No.
> >
> > So,
ering "no route to host" for
your "telnet [ip] 80" session.
I am pretty sure this is not your firewall problem
On Sun, May 29, 2022 at 10:33 AM IL Ka wrote:
>
>
>> When running those, I'm told neither the arptablrs nor the ebtables are
>> registered (not installed). Should I install them?
>
> No.
>
> So, you now have legacy (classic) iptables, right?
Yes.
> What is the output of ``iptables -L -v -n``
> When running those, I'm told neither the arptablrs nor the ebtables are
> registered (not installed). Should I install them?
>
No.
So, you now have legacy (classic) iptables, right?
What is the output of ``iptables -L -v -n`` and ``iptables -S`` ?
On Sun, May 29, 2022 at 09:51 IL Ka wrote:
>
>>> Do I have to switch all four *legacy *tables?
>>
>
> yes
>
When running those, I'm told neither the arptablrs nor the ebtables are
registered (not installed). Should I install them?
>
>
>
>> Do I have to switch all four *legacy *tables?
>
yes
On Sat, May 28, 2022 at 17:24 IL Ka wrote:
> ...
I am not familiar with nft, bit you can switch to iptables using
>> ``update-alternatives``
>>
>
> # update-alternatives --set iptables /usr/sbin/iptables-legacy
> # update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
> #
Le 29/05/2022 à 13:22, Tom Browder a écrit :
On Sun, May 29, 2022 at 05:41 Tom Browder wrote:
Does anyone have a good reason for me to NOT install and enable UFW?
-Tom
good reason would be that thtere is obviously already something on
your server magaing the firewalling. Having 2
>
>
>
> Good to know. But does fail2ban require ipset?
>
No, but having several thousand rules is not convenient, so I prefer ipset
> They never have before in over 15 years, and, before I got this server
> started, its mate was serving fine. But if the ufw doesn't work, I'll ask
> them.
>
I'd
st from one static IP, you probably do not need
> fail2ban at all.
>
Good to know. But does fail2ban require ipset?
Anyway, I am not sure that port 80 is blocked by your firewall and not your
> hosting firewall
>
They never have before in over 15 years, and, before I got this server
s
ed
fail2ban at all.
Anyway, I am not sure that port 80 is blocked by your firewall and not your
hosting firewall
>
> $ telnet x.y.z.w 80
> Trying x.y.z.w...
> telnet: Unable to connect to remote host: No route to host
>
But you can ssh to this host, right?
Well, that means the firewall blocks your request and sends the ICMP
message "no route to host".
Switch to
On Sun, May 29, 2022 at 05:41 Tom Browder wrote:
Does anyone have a good reason for me to NOT install and enable UFW?
-Tom
On Sat, May 28, 2022 at 20:06 IL Ka wrote:
...
3. You should also check that Apache is running and listening to this port,
> use ``ss -lt``.
> For this command you _may_ use sudo to get process names (``sudo ss
> -ltp``). Read ``ss --help``
>
> If you were able to connect on this host, then try
On Sat, May 28, 2022 at 20:06 IL Ka wrote:
>
>> $ sudo su
>> # telnet 80
>> Trying 0.0.0.80...
>>
>
> 1. You are using telnet wrong: it should be "telnet [host] [port]". Please
> read "man telnet".
> 2. You do not need sudo to use telnet, do not do that
> 3. You should also check
>
>
> $ sudo su
> # telnet 80
> Trying 0.0.0.80...
>
1. You are using telnet wrong: it should be "telnet [host] [port]". Please
read "man telnet".
2. You do not need sudo to use telnet, do not do that
3. You should also check that Apache is running and listening to this port,
use ``ss
On Sat, May 28, 2022 at 19:10 Timothy M Butterworth <
timothy.m.butterwo...@gmail.com> wrote:
…
On the local host try running `telnet 127.0.0.1 80`
>
I was able to connect, thanks, Timothy!
Now what? I would really like to use ufw.
-Tom
On Sat, May 28, 2022 at 19:01 Greg Wooledge wrote:
> On Sat, May 28, 2022 at 05:51:38PM -0500, Tom Browder wrote:
> …
>
> ... wow. Just wow. How can such a short excerpt contain so many failures?
Greg, calm down. I get it, but I haven’t unlearned years of muscle
memory—sorry.
And the
g 0.0.0.80...
>>
>>
>> and gave up waiting.
>>
>
On the local host try running `telnet 127.0.0.1 80` If you can not connect
to the web server on the local host then it is likely not running. Try
running `sudo service --status-all` `sudo systemctl enable apache2` and
`sudo service apache2 start`
> Maybe I should remove all firewall progs and start from zero.
>
>
On Sat, May 28, 2022 at 05:51:38PM -0500, Tom Browder wrote:
> $ sudo su
> # telnet 80
> Trying 0.0.0.80...
... wow. Just wow. How can such a short excerpt contain so many failures?
1) "sudo su" is stupid. You don't need TWO setuid programs to get a root
shell. Either use
om home? Do you see apache
>> listening this port using ``ss``?
>>
>
> On the new host I did:
>
> $ sudo su
> # telnet 80
> Trying 0.0.0.80...
>
>
> and gave up waiting.
>
Maybe I should remove all firewall progs and start from zero.
On Sat, May 28, 2022 at 17:30 IL Ka wrote:
> I am running an Apache server and using Qualys Lab’s server checker. It
>> shows no access to the server.
>>
>> Have you tried to telnet to port 80 from home? Do you see apache
> listening this port using ``ss``?
>
On the new host I did:
$ sudo
>
> I am running an Apache server and using Qualys Lab’s server checker. It
> shows no access to the server.
>
> Have you tried to telnet to port 80 from home? Do you see apache
listening this port using ``ss``?
>
> Whatever attempt I make to change the ports disappears when I reboot.
>
> Sure,
2ban and nft
> tables, so I
> need help on how to properly allow https and http inbound.
We have established that you do not have a firewall on your
machine blocking ports. iptables and nftables control the same
underlying mechanism, and you have clearly set the policy to
ACCEPT.
Therefore,
On Sat, May 28, 2022 at 17:08 Dan Ritter wrote:
…
Therefore, something outside of your machine is blocking the
> ports, or you are misreading or misusing the tools that are
> telling you the ports are blocked.
Tell us how you are checking the ports
I am running an Apache server and using
>
>
>
> A little more digging shows the new server is using fail2ban and nft
> tables, so I
> need help on how to properly allow https and http inbound.
>
>
I am not familiar with nft, bit you can switch to iptables using
``update-alternatives``
# update-alternatives --set iptables
On Sat, May 28, 2022 at 14:11 Tom Browder wrote:
> As the bare-iron server came from my long-time cloud provider (since
> Debian 6), incoming ports 80 and 443 are blocked.
A little more digging shows the new server is using fail2ban and nft
tables, so I
need help on how to properly allow https
>
>
>
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -N f2b-sshd
> -A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
> -A f2b-sshd -s 62.204.41.56/32 -j REJECT --reject-with
> icmp-port-unreachable
> -A f2b-sshd -s 61.177.173.48/32 -j REJECT --reject-with
> icmp-port-unreachable
>
On 5/28/22 22:11, Tom Browder wrote:
> As the bare-iron server came from my long-time cloud provider (since
> Debian 6), incoming ports 80 and 443 are blocked.
>
> I ran my usual iptables command for new servers from them, but this
> time the default settings were different so it didn't work.
Tom Browder wrote:
> As the bare-iron server came from my long-time cloud provider (since
> Debian 6), incoming ports 80 and 443 are blocked.
>
> I ran my usual iptables command for new servers from them, but this
> time the default settings were different so it didn't work.
>
> Output from
As the bare-iron server came from my long-time cloud provider (since
Debian 6), incoming ports 80 and 443 are blocked.
I ran my usual iptables command for new servers from them, but this
time the default settings were different so it didn't work.
Output from "sudo iptables -S" before my attempt:
- Mail original -
> De: "JUPIN Alain"
> À: "Liste Debian"
> Envoyé: Jeudi 21 Avril 2022 09:26:49
> Objet: Firewall iptables qui ne bloque pas le port 53
> Bonjour,
> Je vous soumet un petit problème ... sur une install Debian 11, j'ai
>
).
Voici donc les règles de mon firewall
# Politique par defaut
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT
ip6tables -t filter -P INPUT DROP
ip6tables -t filter -P FORWARD DROP
ip6tables -t filter -P
Bonsoir,
Je pense avoir résolu mon souci, non pas avec la MTU mais en redémarrant
la VM.
J'ai l'impression que la prise en compte de la config réseau, notamment
de la désactivation de l'autoconf de l'IPv6, n'a pas été totale la
première fois?
Car maintenant, même avec le firewall actif
connexion tombe !
Sous SSH, plus de réponse puis : "client_loop: send disconnect: Broken
pipe", les autres service aussi ne répondent plus en IPv6
Fait "intriguant", la connexion IPv4 fonctionne parfaitement. Si je
désactive le firewall, tout rentre dans l'ordre. Si je le réacti
xion IPv4 fonctionne parfaitement. Si je
désactive le firewall, tout rentre dans l'ordre. Si je le réactive,
tout fonctionne jusqu'à ce que ... patatrac !
Si je désactive le firewall, aucun soucis, je reste connecté en IPv6
sans limitations de durée (au moins pendant plusieurs heures).
L'hôte de la mach
On 8/11/21 7:01 PM, Alain D D Williams wrote:
On Wed, Aug 11, 2021 at 11:50:30PM +0200, deloptes wrote:
Alain D D Williams wrote:
iptables -A FORWARD -j ACCEPT
and the OUTPUT?
OUTOUT is also ACCEPT, however this is not, I think, important as the packets
come from 10.239.239.23 (via br0)
gt; check traffic with sniffer (no packet should be forwarded from virt machine
> to the Internet)
It now works all of a sudden I am scratching my head to see what I have
changed. The only thing is rebooting the virtual machine that I was testing
from. I cannot see that that should have made a
>
>
>
> > > iptables -A FORWARD -j ACCEPT
>
Are you sure your packets are forwarded via netfilter?
Try to disable forwarding (with sysctl) or change rulte to -j DROP and
check traffic with sniffer (no packet should be forwarded from virt machine
to the Internet)
On Wed, Aug 11, 2021 at 11:50:30PM +0200, deloptes wrote:
> Alain D D Williams wrote:
>
> > iptables -A FORWARD -j ACCEPT
> >
>
> and the OUTPUT?
OUTOUT is also ACCEPT, however this is not, I think, important as the packets
come from 10.239.239.23 (via br0) and go to the Internet - thus
Alain D D Williams wrote:
> iptables -A FORWARD -j ACCEPT
>
and the OUTPUT?
> and this is not a problem ... evidence is outgoing packets with source
> address 10.239.239.23
ah, ok, I misinterpreted it.
--
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
On Wed, Aug 11, 2021 at 11:32:51PM +0200, deloptes wrote:
> I remember it was not only the POSTROUTING. May be I am wrong, but I think
> FORWARD and OUTPUT is important.
> I also wonder why you are mixing up the -s and --to-source. You should be
> using the local address for -s and --to-source
23 I ping the BBC (212.58.249.145) and look with a packet
> sniffer on the BB modem I see outgoing addresses 10.239.239.23
>
> This should not happen. I am running an iptables firewall that should fix
> this with the rule below:
>
> iptables -t nat -A POSTROUTING -s 10.239.239
1 - 100 of 5300 matches
Mail list logo
