On Mon, May 16, 2022 at 2:28 AM Janne Johansson wrote:
> While I can see the appeal of trying, it still means the service is
> not really made to work for more than one client from that same NAT
> pool. Might be fine if you aim for "bill and bob and jenny who works
> from home" coming in from
On Mon, May 16, 2022 at 6:23 AM Philipp Buehler
wrote:
> Back in the days outgoing (tcp) connections had predictable port
> numbers,
> sequence numbers, time based stamps of kinds and so on. This did change
> like "let's random all the things" and this was not only against
> fingerprinting
> but
...on 2022-05-16 17:57:06, Stuart Henderson wrote:
> On 2022-05-16, Alexander Bochmann wrote:
> > I seem to remember firewall rules that allowed only udp/53 as _source_
> > port
> > for DNS traffic.
> Such rules often existed to cover replies, before the days
> of stateful firewalls.
I
On 2022-05-16, Alexander Bochmann wrote:
> Hi,
>
> ...on 2022-05-16 13:23:31, Philipp Buehler wrote:
>
> > I cannot recall many applications from 20y ago that have been very keen
> > on sending from certain ports (besides IKE already mentioned by JJ).
>
> I seem to remember firewall rules that
Hi,
...on 2022-05-16 13:23:31, Philipp Buehler wrote:
> I cannot recall many applications from 20y ago that have been very keen
> on sending from certain ports (besides IKE already mentioned by JJ).
I seem to remember firewall rules that allowed only udp/53 as _source_ port
for DNS traffic.
Elias Carter wrote:
> I have found that preserving the source port if possible works better
> out of the box when hosting publicly accessable UDP applications
> within a private network.
Preserving the source port also works better for attacking services...
I don't see anything strange in what
Am 16.05.2022 10:20 schrieb Elias Carter:
One possible advantage of randomizing source ports is that it helps
prevent fingerprinting of the devices behind the NAT? Are there any
other reasons?
Back in the days outgoing (tcp) connections had predictable port
numbers,
sequence numbers, time
Den mån 16 maj 2022 kl 10:35 skrev Elias Carter :
> OpenBSD/PF defaults to randomizing the source port whereas
> Linux/IPTables defaults to trying to keep the source port.
>
> I have found that preserving the source port if possible works better
> out of the box when hosting publicly accessable
In PF the default behaviour of `nat-to` is to overwrite the source
port of the outgoing packet with a random unused port number. You can
specify `static-port` to preserve the source port number.
In IPTables the default behaviour of the MASQUERADE and SNAT policies
is to try and preserve the
9 matches
Mail list logo
