On Mon, Dec 23, 2024 at 9:05 PM Greg Wooledge wrote:
> On Mon, Dec 23, 2024 at 20:48:12 -0500, Dan Purgert wrote:
> > On Dec 23, 2024, Timothy M Butterworth wrote:
> > > sudo fails with a permission denied error.
> > > tmb@hp-debian:~$ sudo /usr/sbin/iptables-sa
Hi,
On 23 Dec 2024 at 20:56:14, Greg Wooledge wrote:
> On Mon, Dec 23, 2024 at 20:48:12 -0500, Dan Purgert wrote:
> > On Dec 23, 2024, Timothy M Butterworth wrote:
> > > sudo fails with a permission denied error.
> > > tmb@hp-debian:~$ sudo /usr/sbin/iptables-sa
On Mon, Dec 23, 2024 at 20:48:12 -0500, Dan Purgert wrote:
> On Dec 23, 2024, Timothy M Butterworth wrote:
> > sudo fails with a permission denied error.
> > tmb@hp-debian:~$ sudo /usr/sbin/iptables-save > /etc/iptables/rules.v4
> > bash: /etc/iptables/rules.v4: Permission
On Dec 23, 2024, Timothy M Butterworth wrote:
> sudo fails with a permission denied error.
> tmb@hp-debian:~$ sudo /usr/sbin/iptables-save > /etc/iptables/rules.v4
> bash: /etc/iptables/rules.v4: Permission denied
"sudo" only modifies "iptables-save", and not the r
sudo fails with a permission denied error.
tmb@hp-debian:~$ sudo /usr/sbin/iptables-save > /etc/iptables/rules.v4
bash: /etc/iptables/rules.v4: Permission denied
Root user works
tmb@hp-debian:~$ su -l
Password:
Root user with sudo
root@hp-debian:/home/tmb# sudo /usr/sbin/iptables-save >
>> On Thu, 19 Sep 2024, fxkl4...@protonmail.com wrote:
> in my iptables i havetcp LOG flags 0 level 4 prefix "REJECT: "
> this does what i want but how to direct the logging
> it gets written to multiple file in /var/log
> syslog, messages, kern, debug
> can i
On Thu, 19 Sep 2024, fxkl4...@protonmail.com wrote:
in my iptables i havetcp LOG flags 0 level 4 prefix "REJECT: "
this does what i want but how to direct the logging
it gets written to multiple file in /var/log
syslog, messages, kern, debug
can i restrict this to a single file
Hi,
On Thu, Sep 19, 2024 at 02:35:24PM +, fxkl4...@protonmail.com wrote:
> in my iptables i havetcp LOG flags 0 level 4 prefix "REJECT: "
> this does what i want but how to direct the logging
> it gets written to multiple file in /var/log
> syslog, messages, kern,
in my iptables i havetcp LOG flags 0 level 4 prefix "REJECT: "
this does what i want but how to direct the logging
it gets written to multiple file in /var/log
syslog, messages, kern, debug
can i restrict this to a single file
On 2024-08-06, Dan Ritter wrote:
> 200 is a lot for a human to manage. You may be able to simplify your
> iptables rules by taking advantage of ipset for large numbers of
> IPs (hash:ip) or ports (bitmap:port) that need similar
> treatment. That's available in nftables as well.
Wesley wrote:
> We have several debian servers, all running iptables. On average each has 200
> rules, mostly deny rules. From a best practice perspective, do we need to
> upgrade to nftables?
>
iptables is currently implemented in terms of nftables. While it
is possible that
вт, 6 авг. 2024 г. в 16:05, Wesley :
> We have several debian servers, all running iptables. On average each has 200
> rules, mostly deny rules. From a best practice perspective, do we need to
> upgrade to nftables?
Upgrade right now? No.
Check and test? Yes.
If your configuration
We have several debian servers, all running iptables. On average each has 200
rules, mostly deny rules. From a best practice perspective, do we need to
upgrade to nftables?
Thanks & regards.
Got the idea (nft) and thanks for all help.
On 2024-07-03 04:22, Tim Woodall wrote:
On Tue, 2 Jul 2024, Jeff Peng wrote:
Hello gurus,
Is there a tool for maintaining the timeout for iptables rules?
for example, one IP would be blocked by my iptables for 24 hours, and
another IP should be
On Tue, 2 Jul 2024, Jeff Peng wrote:
Hello gurus,
Is there a tool for maintaining the timeout for iptables rules?
for example, one IP would be blocked by my iptables for 24 hours, and another
IP should be blocked for one week.
Off the top of my head I can't think exactly how to do i
Max Nikulin wrote:
> On 02/07/2024 19:28, Dan Ritter wrote:
> > iptables (which are currently implemented in nftables) don't have a native
> > timeout;
>
> nft sets have the timeout option. Isn't it to specify interval of time to
> remove elements?
It works w
On 02/07/2024 19:28, Dan Ritter wrote:
iptables (which are currently implemented in nftables) don't have a native
timeout;
nft sets have the timeout option. Isn't it to specify interval of time
to remove elements?
Jeff Peng wrote:
> Is there a tool for maintaining the timeout for iptables rules?
>
> for example, one IP would be blocked by my iptables for 24 hours, and
> another IP should be blocked for one week.
iptables (which are currently implemented in nftables) don't have a native
Hello gurus,
Is there a tool for maintaining the timeout for iptables rules?
for example, one IP would be blocked by my iptables for 24 hours, and
another IP should be blocked for one week.
Thanks.
On 24 May 2024 23:23:44 BST, Andy Smith wrote:
>You will likely get better performance if you switch to nftables and
>use an ipset to hold all the bans, though I've no idea how easy
>that is to configure with fail2ban.
It's easy, supported out of the box. I have been using nftables for years w
Hi,
On Sat, May 25, 2024 at 06:04:34AM +0800, Northwind wrote:
> I have been using a KVM vps with 2G ram, 2 cores.
> due to fail2ban jobs, iptables in this vps has dropped 3000+ black IPs.
> may I ask how max iptables rules the VPS can have?
It depends upon the kind of rule but for
Hello
I have been using a KVM vps with 2G ram, 2 cores.
due to fail2ban jobs, iptables in this vps has dropped 3000+ black IPs.
may I ask how max iptables rules the VPS can have?
does many iptables rules influence the networking performance?
Thanks
Henggi writes:
> Oh wow… that’s interesting. I had no idea about „nft“ (I just knew
> „iptables-nft“) which seem to be very different.
> I think I have dig down where those „nft" rules are coming from while
> iptables-nft is completely empty. Thanks, great clue!
Typically
t; What does
>
> nft list ruleset
>
> show?
> (Unfortunately, this is all I know about netfilter diagnostics... and I
> couldn't even get this far without internet search engine :-)
Oh wow… that’s interesting. I had no idea about „nft“ (I just knew
„iptables-nft“) which se
> On 24 Oct 2023, at 16:33, Max Nikulin wrote:
>
> On 24/10/2023 19:04, Henggi wrote:
>> - iptables on server are cleared/open (firewalld or other firewall
>> frameworks are not used/installed).
>
> Nowadays nft or iptables is not the only option to drop packets.
> On 24 Oct 2023, at 17:22, Charles Curley
> wrote:
>
> On Tue, 24 Oct 2023 15:30:14 +0200
> Arno Lehmann wrote:
>
>> Recently I encountered something similar, and my usual test for local
>> firewall being active,
>>
>> iptables -L -n
>>
Hello,
Am 24.10.2023 um 16:19 schrieb Henggi:
...
As I mentioned in my 1st email, I think (afaik) that no other netfitler
module/service is running.
My anecdote was intended to illustrate that beliefs are not really good
tools to diagnose problems ;-)
root@server:~# systemctl status firew
On Tue, 24 Oct 2023 15:30:14 +0200
Arno Lehmann wrote:
> Recently I encountered something similar, and my usual test for local
> firewall being active,
>
> iptables -L -n
>
> came back with policies "accept" all over the place, and no
> particular rules.
>
pp listening
>> process (while other services on same host are working just fine via the
>> network - so it’s not an „physical" network issue).
>> -> iptables are cleared and not aware of any other netfilter running…
>
> I suggest to verify the other netfiler
On 24/10/2023 19:04, Henggi wrote:
- iptables on server are cleared/open (firewalld or other firewall
frameworks are not used/installed).
Nowadays nft or iptables is not the only option to drop packets. Another
one is eBPF used e.g. by systemd.
I have the following link in my notes, but I
other machine and this one. It could be on that other machine,
> on this machine, or in some network device between them.
My assumption too (unless it’s a weird bug within used pkg version of xrdp)…
thats why i provided evidence of the cleared iptables & tcpdump before
How to figure out wher
otherwise:
-> incoming tcp syn/ack on localhost interfact (lo) works fine
-> incoming tcp syn/ack on eth0 interface seems not to reach app listening process
(while other services on same host are working just fine via the network - so it’s not
an „physical" network issue).
-> iptables are c
Henggi wrote:
>
> > On 24 Oct 2023, at 14:46, Dan Ritter wrote:
> >
> - when using „port=tcp://:3389“ in xrdp.ini:
> root@server:~# ss -tlnp | grep 3389
> LISTEN 0 2 0.0.0.0:3389 0.0.0.0:*
> users:(("xrdp",pid=96436,fd=11))
>
> - when using using „port=3389“ in x
> On 24 Oct 2023, at 14:46, Dan Ritter wrote:
>
> Henggi wrote:
>> Hi list,
>>
>> Completely stuck here, any clue appreciated!
>>
>> — by default xrdp.ini listening config is set to "port=3389“ (which is
>> expected to listen on ipv4 && ipv6 in parallel as I understand). However
>> using t
Henggi wrote:
> Hi list,
>
> Completely stuck here, any clue appreciated!
>
> — by default xrdp.ini listening config is set to "port=3389“ (which is
> expected to listen on ipv4 && ipv6 in parallel as I understand). However
> using that seems only to listen on tcp4 according to „netstat“
> — t
(lo) works fine
-> incoming tcp syn/ack on eth0 interface seems not to reach app listening
process (while other services on same host are working just fine via the
network - so it’s not an „physical" network issue).
-> iptables are cleared and not aware of any other net
Hello,
On Mon, May 15, 2023 at 09:40:10AM +0800, Tom Reed wrote:
> Yes after each telnet from client host, the count was increased.
>
> 0 0 REJECT tcp -- anyany anywhere
> anywhere tcp dpt:imaps reject-with tcp-reset
> 0 0 REJECT tcp --
> Hello,
>
> On Mon, May 15, 2023 at 09:10:24AM +0800, Tom Reed wrote:
>> If I clean iptables in the destination host, this telnet will get
>> success
>> at once.
>>
>> Any hints?
>
> Why have you not used "iptables -vL" to show the pack
Hello,
On Mon, May 15, 2023 at 09:10:24AM +0800, Tom Reed wrote:
> If I clean iptables in the destination host, this telnet will get success
> at once.
>
> Any hints?
Why have you not used "iptables -vL" to show the packet counts of
each rule so you can see which rules t
is LA), both
got timeout, rather than the expected disconnection quickly.
$ telnet 193.106.250.86 587
Trying 193.106.250.86...
telnet: Unable to connect to remote host: Connection timed out
If I clean iptables in the destination host, this telnet will get success
at once.
Any hints?
Thanks.
--
Hi,
On Sun, May 14, 2023 at 08:14:04AM +0800, Tom Reed wrote:
> I have these iptables rules which reject tcp connections with tcp rst.
First question, why are you using iptables instead of nft? On a new
Debian install you actually are using nftables with an iptables
compat layer, but a
tcptraceroute might give you more clues as to where it's going wrong. In
particular I'd look at local egress rules not allowing connections to
port 587 outside of the lan.
On Sun, 14 May 2023, Tom Reed wrote:
On Sun, May 14, 2023 at 08:36:38AM +0800, Tom Reed wrote:
tcp0 0 0.0.0.0
> On Sun, May 14, 2023 at 08:36:38AM +0800, Tom Reed wrote:
>> tcp0 0 0.0.0.0:587 0.0.0.0:*
>> LISTEN
>> 32157/master
>>
>>
>> And the telnet results:
>>
>> $ telnet 193.106.250.xx 587
>> Trying 193.106.250.xx...
>> telnet: Unable to connect to remote host: Connection
On 14 May 2023 02:36, Tom Reed wrote:
$ telnet 193.106.250.xx 587
Trying 193.106.250.xx...
telnet: Unable to connect to remote host: Connection timed out
Run wireshark/dumpcap or tcpdump on the client to check if you get the
TCP reset packet.
You can also run it server-side, to see if the ser
On Sun, May 14, 2023 at 08:36:38AM +0800, Tom Reed wrote:
> tcp0 0 0.0.0.0:587 0.0.0.0:* LISTEN
> 32157/master
>
>
> And the telnet results:
>
> $ telnet 193.106.250.xx 587
> Trying 193.106.250.xx...
> telnet: Unable to connect to remote host: Connecti
>
> On 14/5/23 08:28, Tom Reed wrote:
>> I telnet to host:587 not the port 23.
>> And port 587 already reject access with tcp rst.
> --
>
> check if you are listening on port 587
>
> netstat -tulpnW | grep 587
>
>
yes it does.
tcp0 0 0.0.0.0:587 0.0.0.0:* LI
On 14/5/23 08:28, Tom Reed wrote:
I telnet to host:587 not the port 23.
And port 587 already reject access with tcp rst.
--
check if you are listening on port 587
netstat -tulpnW | grep 587
Jeremy
>
> On 14/5/23 08:14, Tom Reed wrote:
>> /usr/sbin/iptables -A INPUT -p tcp --dport 143 -j REJECT --reject-with
>> tcp-reset
>> /usr/sbin/iptables -A INPUT -p tcp --dport 587 -j REJECT --reject-with
>> tcp-reset
>>
>> When I telnet from another h
On 14/5/23 08:14, Tom Reed wrote:
/usr/sbin/iptables -A INPUT -p tcp --dport 143 -j REJECT --reject-with
tcp-reset
/usr/sbin/iptables -A INPUT -p tcp --dport 587 -j REJECT --reject-with
tcp-reset
When I telnet from another host to the protected port, it gets timeout
message as follows
Hello
I have these iptables rules which reject tcp connections with tcp rst.
/usr/sbin/iptables -A INPUT -p tcp --dport 143 -j REJECT --reject-with
tcp-reset
/usr/sbin/iptables -A INPUT -p tcp --dport 587 -j REJECT --reject-with
tcp-reset
When I telnet from another host to the protected port
>
> On 13/5/23 18:56, Tom Reed wrote:
>> for iptables-save, after system rebooting, does it know where to locate
>> the file?
>
> Yes. That's all taken care of by the iptables-persistent package
>
> Also I made a typo. correction;
>
> sudo nano /etc/ipta
On 13/5/23 18:56, Tom Reed wrote:
for iptables-save, after system rebooting, does it know where to locate
the file?
Yes. That's all taken care of by the iptables-persistent package
Also I made a typo. correction;
sudo nano /etc/iptables/rules.v4
sudo nano /etc/iptables/rul
>
> On 13/5/23 18:48, Tom Reed wrote:
>> How to recovery iptable rules after system rebooting?
>> I know I can put a @reboot crontab for this but there is maybe the
>> better
>> way.
>
>
> sudo apt install iptables-persistent
>
> sudo iptables-save >
On 13/5/23 18:48, Tom Reed wrote:
How to recovery iptable rules after system rebooting?
I know I can put a @reboot crontab for this but there is maybe the better
way.
sudo apt install iptables-persistent
sudo iptables-save > /etc/iptables/rules.v4
sudo ip6tables-save > /etc/ip
Hello
How to recovery iptable rules after system rebooting?
I know I can put a @reboot crontab for this but there is maybe the better
way.
Thanks
Thanks John.
The following rules seem to work for me now.
sudo /usr/sbin/iptables -F
sudo /usr/sbin/iptables -A INPUT -m state --state RELATED,ESTABLISHED -j
ACCEPT
sudo /usr/sbin/iptables -A INPUT -p icmp -j ACCEPT
sudo /usr/sbin/iptables -A INPUT -i lo -j ACCEPT
sudo /usr/sbin/iptables -A
John Conover writes:
> =?UTF-8?B?UGlwZXLjgb/jgYvjgZM=?= writes:
> >
> > sudo /usr/sbin/iptables -F
> > sudo /usr/sbin/iptables -A INPUT -s 127.0.0.1 -j ACCEPT
> > sudo /usr/sbin/iptables -A INPUT -s xx.xx.xx.xx -j ACCEPT # my server
> > public IP
> >
=?UTF-8?B?UGlwZXLjgb/jgYvjgZM=?= writes:
>
> sudo /usr/sbin/iptables -F
> sudo /usr/sbin/iptables -A INPUT -s 127.0.0.1 -j ACCEPT
> sudo /usr/sbin/iptables -A INPUT -s xx.xx.xx.xx -j ACCEPT # my server
> public IP
> sudo /usr/sbin/iptables -A INPUT -p tcp --dport 22 -j ACCEP
rsync connection to another server
from that box, it won't work (connection timeout).
So how to ?
Thanks
On Sun, Dec 25, 2022 at 10:28 AM jeremy ardley wrote:
>
> On 25/12/22 10:14, Piperみかこ wrote:
> > Hello,
> >
> > I have setup the following iptables on linux server,
Piperみかこ wrote:
> Hello,
>
> I have setup the following iptables on linux server,
>
> sudo /usr/sbin/iptables -F
> sudo /usr/sbin/iptables -A INPUT -s 127.0.0.1 -j ACCEPT
> sudo /usr/sbin/iptables -A INPUT -s xx.xx.xx.xx -j ACCEPT # my server
> public IP
> sudo /us
On 25/12/22 10:14, Piperみかこ wrote:
Hello,
I have setup the following iptables on linux server,
sudo /usr/sbin/iptables -F
sudo /usr/sbin/iptables -A INPUT -s 127.0.0.1 -j ACCEPT
sudo /usr/sbin/iptables -A INPUT -s xx.xx.xx.xx -j ACCEPT # my server
public IP
sudo /usr/sbin/iptables -A
Hello,
I have setup the following iptables on linux server,
sudo /usr/sbin/iptables -F
sudo /usr/sbin/iptables -A INPUT -s 127.0.0.1 -j ACCEPT
sudo /usr/sbin/iptables -A INPUT -s xx.xx.xx.xx -j ACCEPT # my server
public IP
sudo /usr/sbin/iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo /usr
On 02.04.2021 14:23, William Torrez Corea wrote:
Actually i'm moving/migrating from the old iptables/xtables (legacy)
world to the new nftables framework.
I execute step by step the migration process:
1. generate a translation of an iptables/ip6tables command to know
the nft
On 4/2/21 12:23 PM, William Torrez Corea wrote:
> Actually i'm moving/migrating from the old iptables/xtables (legacy)
> world to the new nftables framework.
>
> I execute step by step the migration process:
>
> 1. generate a translation of an iptables/ip6tab
Actually i'm moving/migrating from the old iptables/xtables (legacy) world
to the new nftables framework.
I execute step by step the migration process:
1. generate a translation of an iptables/ip6tables command to know the
nftables equivalent
2. Translate the whole ruleset in a s
ewall rules. [It starts near] the top with some lines that have
been there for ever. After upgrading to buster I got an error
executing this script and I cannot find out why. Using the extra echo
lines I have been able to pinpoint the error to the iptables -Z line
[...]
IPTABLES=/usr/sbin/iptables
p with some lines that have
> been there for ever. After upgrading to buster I got an error
> executing this script and I cannot find out why. Using the extra echo
> lines I have been able to pinpoint the error to the iptables -Z line
>
> [...]
> IPTABLES=/usr/sbin/iptables
>
pinpoint the error
to the iptables -Z line
[...]
IPTABLES=/usr/sbin/iptables
echo flush
# Flush all rules in all chains and then delete all chains
chains=`cat /proc/net/ip_tables_names 2>/dev/null`
for i in $chains; do $IPTABLES -t $i -F; done
for i in $chains; do $IPTABLES -t $i -X; done
e
On 2020-11-06 11:43, Sven Hartge wrote:
Jesper Dybdal wrote:
* The CT target, to add the ftp helper. I fixed that by adding a bit of
native nft with the nft command after all the iptables(-nft) commands.
For the sake of the archive and people looking at this thread hoping for
some insight
Jesper Dybdal wrote:
> * The CT target, to add the ftp helper. I fixed that by adding a bit of
> native nft with the nft command after all the iptables(-nft) commands.
For the sake of the archive and people looking at this thread hoping for
some insight, please post your native nft rul
On 2020-10-16 12:25, I wrote:
I have a lot of iptables rules.
Is it correctly understood that the upgrade to Buster will
automatically install iptables-nft, and that iptablés-nft provides
complete and compatible support for the functionality of the old
iptables command, so I can expect my
Le vendredi 16 octobre 2020 à 14:12:55+0200, Jesper Dybdal a écrit :
>
> On 2020-10-16 12:35, Reco wrote:
> > Barring some kernel bugs - yes.
> > For instance, I've seen kernel panics because of simple:
> >
> > iptables -A INPUT -m conntrack --ctstate INVA
On 2020-10-16 12:35, Reco wrote:
Barring some kernel bugs - yes.
For instance, I've seen kernel panics because of simple:
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
Aargh! I had not realized that I would have to be prepared for kernel
panics during the upgrade, so I r
Hi.
On Fri, Oct 16, 2020 at 12:25:23PM +0200, Jesper Dybdal wrote:
> I have a lot of iptables rules.
>
> Is it correctly understood that the upgrade to Buster will automatically
> install iptables-nft, and that iptablés-nft provides complete and compatible
> su
I have a lot of iptables rules.
Is it correctly understood that the upgrade to Buster will automatically
install iptables-nft, and that iptablés-nft provides complete and
compatible support for the functionality of the old iptables command, so
I can expect my iptables scripts to just work
imes a day. And that was eating
> > > up my bandwidth allocation on a slow net connection.
> > >
> > > Is there a tut someplace to guide one in converting from iptables
> > > to this newer nftables? I'm assumeing its a similar utility.
> >
> > Sur
ned to deny the
> > network spiders and bots that think they have to mirror my several
> > giga-byte site, 2 or 3 times a day. And that was eating up my bandwidth
> > allocation on a slow net connection.
> >
> > Is there a tut someplace to guide one in converting from
gt; Is there a tut someplace to guide one in converting from iptables to this
> newer nftables? I'm assumeing its a similar utility.
Sure, but I have not looked into ... I only read there will be a couple of
years transition period and somehow a compatibility layer is or can be
used.
Perhap
nse. You're just inventing incorrect explanations
for whatever behavior you're seeing that you don't understand.
If an /etc/rc.local file exists and has the execute bit turned on, it
is executed AS ROOT at BOOT TIME, before there is any "logged in user".
> that has hidden the
On Monday 24 August 2020 04:45:01 Andrei POPESCU wrote:
> On Du, 23 aug 20, 21:34:12, Gene Heskett wrote:
> > On Sunday 23 August 2020 15:45:22 Joe wrote:
> > > My server iptables is inherited from, I think, sarge, so it's
> > > probably not done optimally tod
On Du, 23 aug 20, 21:34:12, Gene Heskett wrote:
> On Sunday 23 August 2020 15:45:22 Joe wrote:
> >
> > My server iptables is inherited from, I think, sarge, so it's probably
> > not done optimally today. It's an init script run from /etc/rcS.d.
>
> Ah,/etc/rcS
On Sun, 23 Aug 2020 21:34:12 -0400
Gene Heskett wrote:
> On Sunday 23 August 2020 15:45:22 Joe wrote:
>
> >
> > My server iptables is inherited from, I think, sarge, so it's
> > probably not done optimally today. It's an init script run from
> > /etc/
On Sun, 2020-08-23 at 14:26 -0400, Gene Heskett wrote:
> Greetings all;
>
> Since the big conversion of file structs vs who owns what, which
> apparently includes running rc.local as the logged in user and not
> as
> root, that has hidden the iptables stuff from everybod
On Sunday 23 August 2020 16:10:10 deloptes wrote:
> Hi Gene,
>
> Gene Heskett wrote:
> > Since the big conversion of file structs vs who owns what, which
> > apparently includes running rc.local as the logged in user and not
> > as root, that has hidden the iptables st
ser and not
> > as root, that has hidden the iptables stuff from everybody but root
> > since its not now in the users $PATH.
> >
> > So what is the best way to assure this stuff gets started during a
> > reboot or restart of X? Stuff that s/b running regardless of any X
&
Hi Gene,
Gene Heskett wrote:
> Since the big conversion of file structs vs who owns what, which
> apparently includes running rc.local as the logged in user and not as
> root, that has hidden the iptables stuff from everybody but root since
> its not now in the users $PATH.
>
On Sun, 23 Aug 2020 14:26:19 -0400
Gene Heskett wrote:
> Greetings all;
>
> Since the big conversion of file structs vs who owns what, which
> apparently includes running rc.local as the logged in user and not as
> root, that has hidden the iptables stuff from everybody but r
Greetings all;
Since the big conversion of file structs vs who owns what, which
apparently includes running rc.local as the logged in user and not as
root, that has hidden the iptables stuff from everybody but root since
its not now in the users $PATH.
So what is the best way to assure this
translated to
> an ipv4 address somehow, and I may have inadvertently blocked it with
> an iptables rule in my war against the robots that were burning up my
> upload bandwidth.
>
> How do I go about determiniing that KCKB's ip address? Or, how is
> that determined?
>
> Tha
to just look it up.
> I use the gkrellm weather pluggin to get me an uptodate weather report
> from the nearby airports call sign, but this has to be translated to an
> ipv4 address somehow, and I may have inadvertently blocked it with an
> iptables rule in my war against the robots tha
s to be translated to an
> ipv4 address somehow, and I may have inadvertently blocked it with an
> iptables rule in my war against the robots that were burning up my
> upload bandwidth.
>
> How do I go about determiniing that KCKB's ip address? Or, how is that
> determin
an
iptables rule in my war against the robots that were burning up my
upload bandwidth.
How do I go about determiniing that KCKB's ip address? Or, how is that
determined?
Thanks.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury
On Sb, 20 iun 20, 14:37:34, Tom Browder wrote:
>
> I have no love for iptables and very little experience with it. So it seems
> I should remove the iptables package and install the nftables one. And I'll
> look into firewalld which I tried briefly some years ago.
In case yo
On Sat, Jun 20, 2020 at 12:44 Ben Lavender wrote:
> Personally I'd learn nf_tables because that's the way forward and if you
> stick to it's CLI then the better.
>
Thanks, Ben.
-Tom
On Sat, Jun 20, 2020 at 10:48 wrote:
> Hi,
>
...
> Actually, as explained on https://wiki.debian.org/nftables, Buster uses
> an "iptables-nft layer (i.e, using iptables syntax with the nf_tables
> kernel subsystem). This also affects ip6tables, arptables and ebtables.
0, 15:25 Tom Browder, wrote:
> I see it's recommended that Buster users use nftables, but the default
> installation still uses iptables!
>
> I need to change ports on my new remote server to allow http and https
> traffic, but should I keep using iptables? Or should I remove iptab
Hi,
20 juin 2020 à 16:24 de tom.brow...@gmail.com:
> I see it's recommended that Buster users use nftables, but the default
> installation still uses iptables!
>
True & false.
Actually, as explained on https://wiki.debian.org/nftables, Buster uses an
"iptables-nft lay
I see it's recommended that Buster users use nftables, but the default
installation still uses iptables!
I need to change ports on my new remote server to allow http and https
traffic, but should I keep using iptables? Or should I remove iptables
and install nftables first?
If I keep ipt
Hi,
[]
> Right, your basic problem is that your interfaces are now names
> enp7s0
> and
> wlp6s0
>
> not eth0 and wifi0 or whatever they used to be.
>
> Fix them in /etc/network/interfaces, double check your iptables rules
> are either using the new names or don&
etc/network/interfaces"
>> > failed.
>
> Right, your basic problem is that your interfaces are now names
> enp7s0
> and
> wlp6s0
>
> not eth0 and wifi0 or whatever they used to be.
>
> Fix them in /etc/network/interfaces, double check your iptables
> rules are either using the new names or don't mention interfaces
> at all, and you should be relatively happy.
or boot with the param to the kernel
net.ifnames=0
songbird
1 - 100 of 1896 matches
Mail list logo
