| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 23 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 49:45:39 |
| Calls: | 583 |
| Files: | 1,138 |
| Messages: | 111,301 |
Having been pointed at nftables as the right direction, I had a word
with chatgpt asking for examples for my use case. I treat the answers
with suspicion, but they seem clear and reasonable, and I'll take a good look when I've time.
(I'd given up on chatgpt ages ago, when it made Noddy mistakes on
trivial code examples. Looks like things have improved since then.)
Thanks all for helpful answers.
pf allows, for example
pfctl -t inboundblock -T replace -f /etc/firewall/inboundblock
which is an atomic operation.
On Wed, 27 Aug 2025 06:56:46 +0100, Mike Scott wrote:troff:<standard input>:1317: warning [p 10, 4.7i, div '3tbd9,1', 0.3i]:
pf allows, for example
pfctl -t inboundblock -T replace -f /etc/firewall/inboundblock
which is an atomic operation.
The docs say
nft -f -2file-+
is an atomic operation. You might have known that if yourCOd read them.
man nft |grep atomic
To be fair, the online wiki does give the answer. Which raises the
issue, again, of documentation standards. When important matters are
absent from at least some key docs, then what?
Again, when important information for *core networking tools* is onlyTo be fair, the online wiki does give the answer. Which raises the
issue, again, of documentation standards. When important matters are
absent from at least some key docs, then what?
WerenrCOt you one of those complaining that bare reference material
wasnrCOt enough? That you wanted tutorial examples and how-tos and all
that? Then when I mention that it all that is available, you now find
a new reason to complain?
On Fri, 29 Aug 2025 00:56:54 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
To be fair, the online wiki does give the answer. Which raises the
issue, again, of documentation standards. When important matters are
absent from at least some key docs, then what?
WerenrCOt you one of those complaining that bare reference material
wasnrCOt enough? That you wanted tutorial examples and how-tos and all
that? Then when I mention that it all that is available, you now find
a new reason to complain?
Again, when important information for *core networking tools* is only
found on the Web, it hardly takes a great sage to discern the problem.
On Fri, 29 Aug 2025 00:56:54 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
WerenrCOt you one of those complaining that bare reference material
wasnrCOt enough? That you wanted tutorial examples and how-tos and
all that? Then when I mention that it all that is available, you
now find a new reason to complain?
Again, when important information for *core networking tools* is
only found on the Web, it hardly takes a great sage to discern the
problem.
On Fri, 29 Aug 2025 08:10:08 -0700, John Ames wrote:
On Fri, 29 Aug 2025 00:56:54 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
WerenrCOt you one of those complaining that bare reference material
wasnrCOt enough? That you wanted tutorial examples and how-tos and
all that? Then when I mention that it all that is available, you
now find a new reason to complain?
Again, when important information for *core networking tools* is
only found on the Web, it hardly takes a great sage to discern the
problem.
The problem is, you donrCOt understand the Web?
Because *everything* is on the Web these days. If you canrCOt figure out basic Web searching, then perhaps you should stay away from computers altogether?
On 2025-08-30, Lawrence DrCOOliveiro wrote:
On Fri, 29 Aug 2025 08:10:08 -0700, John Ames wrote:
On Fri, 29 Aug 2025 00:56:54 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
WerenrCOt you one of those complaining that bare reference material
wasnrCOt enough? That you wanted tutorial examples and how-tos and
all that? Then when I mention that it all that is available, you
now find a new reason to complain?
Again, when important information for *core networking tools* is
only found on the Web, it hardly takes a great sage to discern the
problem.
The problem is, you donrCOt understand the Web?
Because *everything* is on the Web these days. If you canrCOt figure out
basic Web searching, then perhaps you should stay away from computers
altogether?
If there's no network connectivity, your web search skills won't do
much?
If there's no network connectivity, your web search skills won't do much?
On 29/08/2025 16:10, John Ames wrote:
On Fri, 29 Aug 2025 00:56:54 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
To be fair, the online wiki does give the answer. Which raises the
issue, again, of documentation standards. When important matters are
absent from at least some key docs, then what?
WerenrCOt you one of those complaining that bare reference material
wasnrCOt enough? That you wanted tutorial examples and how-tos and all
that? Then when I mention that it all that is available, you now find
a new reason to complain?
Again, when important information for *core networking tools* is only
found on the Web, it hardly takes a great sage to discern the problem.
The problem is that it is /not/ all available. I'm quite stumped about
one particular issue for which there seem no references at all that I
can find: and believe me, I have looked.
Ironically, chatgpt has been a help. It makes so many errors that
sorting them out has been quite educational.
Oh - the problem in hand. No doubt it's easy when you know: single interface, allow all lan traffic, block wan inbound to port 22, redirect
wan inbound on port 12345 to 22 and pass. Block wan inbound otherwise.
If anyone has a config snippet to do this, I'd be very grateful.
On 2025-08-30, Lawrence DrCOOliveiro wrote:
On Fri, 29 Aug 2025 08:10:08 -0700, John Ames wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
WerenrCOt you one of those complaining that bare reference material
wasnrCOt enough? That you wanted tutorial examples and how-tos and
all that? Then when I mention that it all that is available, you
now find a new reason to complain?
Again, when important information for *core networking tools* is
only found on the Web, it hardly takes a great sage to discern the
problem.
The problem is, you donrCOt understand the Web?
Because *everything* is on the Web these days. If you canrCOt figure
out basic Web searching, then perhaps you should stay away from
computers altogether?
If there's no network connectivity, your web search skills won't do
much?
On 29.8.2025 21.16, Mike Scott wrote:
On 29/08/2025 16:10, John Ames wrote:
On Fri, 29 Aug 2025 00:56:54 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
To be fair, the online wiki does give the answer. Which raises the
issue, again, of documentation standards. When important matters are >>>>> absent from at least some key docs, then what?
WerenrCOt you one of those complaining that bare reference material
wasnrCOt enough? That you wanted tutorial examples and how-tos and all >>>> that? Then when I mention that it all that is available, you now find
a new reason to complain?
Again, when important information for *core networking tools* is only
found on the Web, it hardly takes a great sage to discern the problem.
The problem is that it is /not/ all available. I'm quite stumped about
one particular issue for which there seem no references at all that I
can find: and believe me, I have looked.
Ironically, chatgpt has been a help. It makes so many errors that
sorting them out has been quite educational.
Oh - the problem in hand. No doubt it's easy when you know: single
interface, allow all lan traffic, block wan inbound to port 22,
redirect wan inbound on port 12345 to 22 and pass. Block wan inbound
otherwise. If anyone has a config snippet to do this, I'd be very
grateful.
Mike,
The tool you need is called nftables, with a command line
interface program called nft.
Google for nftables documentation, read and understand it, the
response is there with examples. It is difficult to provide a
good snippet without your networking details.
You could also configure the ssh daemon with a secondary port
of 12345, just pass it, to avoid the port translation step.
Oh - the problem in hand. No doubt it's easy when you know: single
interface, allow all lan traffic, block wan inbound to port 22,
redirect wan inbound on port 12345 to 22 and pass. Block wan inbound otherwise. If anyone has a config snippet to do this, I'd be very
grateful.
On 30/08/2025 14:59, Tauno Voipio wrote:
On 29.8.2025 21.16, Mike Scott wrote:
On 29/08/2025 16:10, John Ames wrote:
On Fri, 29 Aug 2025 00:56:54 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
To be fair, the online wiki does give the answer. Which raises the >>>>>> issue, again, of documentation standards. When important matters are >>>>>> absent from at least some key docs, then what?
WerenrCOt you one of those complaining that bare reference material
wasnrCOt enough? That you wanted tutorial examples and how-tos and all >>>>> that? Then when I mention that it all that is available, you now find >>>>> a new reason to complain?
Again, when important information for *core networking tools* is only
found on the Web, it hardly takes a great sage to discern the problem. >>>>
The problem is that it is /not/ all available. I'm quite stumped
about one particular issue for which there seem no references at all
that I can find: and believe me, I have looked.
Ironically, chatgpt has been a help. It makes so many errors that
sorting them out has been quite educational.
Oh - the problem in hand. No doubt it's easy when you know: single
interface, allow all lan traffic, block wan inbound to port 22,
redirect wan inbound on port 12345 to 22 and pass. Block wan inbound
otherwise. If anyone has a config snippet to do this, I'd be very
grateful.
Mike,
The tool you need is called nftables, with a command line
interface program called nft.
Google for nftables documentation, read and understand it, the
response is there with examples. It is difficult to provide a
good snippet without your networking details.
You could also configure the ssh daemon with a secondary port
of 12345, just pass it, to avoid the port translation step.
We're going in circles here.... there's an issue with lack of decent
docs (and examples) for nft - it seems that port blocking occurs after
the redirection, with unhappy consequences, and I find no usable
information suggesting any other possibility.
I have running on freebsd, and am trying to move to linux, a server that ignores port 22 from the net at large, but accepts (similar to) 12345,
just to provide an extra layer of obfuscation to wannabe attackers.
It's a 2-line doddle on freebsd's pf firewall; I can't for the life of
me work out the nftables equivalent, and begin to wonder if indeed it
can be done.
I suppose opening multiple ssh listener ports is another solution
(thanks), but the original problem should - surely - be solvable: it
also pops up for other services but which won't necessarily have the workaround.