On 25/02/2021 17:02, David Sommerseth wrote:
On 25/02/2021 17:56, tincanteksup wrote:
How about ...
On 25/02/2021 01:03, tincanteksup wrote:
Keeping up with the internet is hard:
https://squeeze.isobar.com/2019/04/11/the-sad-story-of-tcp-fast-open/
I guess the bottom line is: Use UDP, if yo
On 25/02/2021 17:56, tincanteksup wrote:
How about ...
On 25/02/2021 01:03, tincanteksup wrote:
Keeping up with the internet is hard:
https://squeeze.isobar.com/2019/04/11/the-sad-story-of-tcp-fast-open/
I guess the bottom line is: Use UDP, if you are worried about TCP SYN
to your server.
I
dang!
On 25/02/2021 16:56, tincanteksup wrote:
How about ...
On 25/02/2021 01:03, tincanteksup wrote:
Keeping up with the internet is hard:
https://squeeze.isobar.com/2019/04/11/the-sad-story-of-tcp-fast-open/
I guess the bottom line is: Use UDP, if you are worried about TCP SYN
to your serv
How about ...
On 25/02/2021 01:03, tincanteksup wrote:
Keeping up with the internet is hard:
https://squeeze.isobar.com/2019/04/11/the-sad-story-of-tcp-fast-open/
I guess the bottom line is: Use UDP, if you are worried about TCP SYN to
your server.
Instead of UDP..
Use --port-share and have
On Thu, Feb 25, 2021 at 09:17:11AM +0100, Jan Just Keijser wrote:
> send raw packets. On linux this is possible, not sure about Windows, but
> it's definitely a no-no on Android or iOS.
If DDoS or cracking attempt is a problem with your setup, and port-knocking is
not applicable, why not add a sim
On 25/02/21 08:12, Marc SCHAEFER wrote:
On Wed, Feb 24, 2021 at 10:49:56PM +, tincanteksup wrote:
My idea (as daft as it is) would only serve one purpose: To hide a
listening TCP port. Because there would be no SYN-ACK from the server if
the SYN failed security checks.
This is what port
On Wed, Feb 24, 2021 at 10:49:56PM +, tincanteksup wrote:
> My idea (as daft as it is) would only serve one purpose: To hide a
> listening TCP port. Because there would be no SYN-ACK from the server if
> the SYN failed security checks.
This is what port knocking does: unfirewall the OpenVPN
Keeping up with the internet is hard:
https://squeeze.isobar.com/2019/04/11/the-sad-story-of-tcp-fast-open/
I guess the bottom line is: Use UDP, if you are worried about TCP SYN to
your server.
___
Openvpn-users mailing list
Openvpn-users@lists.sour
On 24/02/2021 22:30, David Sommerseth wrote:
TFO has a bigger advantage in short-lived TCP sessions (like web
browsers) where you open several independent TCP connections to fetch
data in parallel and then close them down. Here TFO will have an edge.
Agreed.
Now you might argue about the
On 24/02/2021 23:05, tincanteksup wrote:
On 24/02/2021 21:28, tincanteksup wrote:
On 24/02/2021 20:05, Marc SCHAEFER wrote:
On Wed, Feb 24, 2021 at 07:27:09PM +, tincanteksup wrote:
I wonder if IPv6 has any new features which can customise the
initial Syn
packet in any way ?
Not to
On 24/02/2021 21:28, tincanteksup wrote:
On 24/02/2021 20:05, Marc SCHAEFER wrote:
On Wed, Feb 24, 2021 at 07:27:09PM +, tincanteksup wrote:
I wonder if IPv6 has any new features which can customise the initial
Syn
packet in any way ?
Not to my knowledge. Why would you want to do th
On 24/02/2021 20:05, Marc SCHAEFER wrote:
On Wed, Feb 24, 2021 at 07:27:09PM +, tincanteksup wrote:
which suggested to me that openvpn may have some vulnerability to TCP DDos.
A Linux kernel can offer a few protections against DDoS, for example
SYN cookies to avoid a memory exhaustion w
On Wed, Feb 24, 2021 at 07:27:09PM +, tincanteksup wrote:
> which suggested to me that openvpn may have some vulnerability to TCP DDos.
A Linux kernel can offer a few protections against DDoS, for example
SYN cookies to avoid a memory exhaustion with fake TCP connection
openings. You may have
Yep .. got it now, thanks!
On 24/02/2021 19:39, Gert Doering wrote:
Hi,
On Wed, Feb 24, 2021 at 06:01:19PM +, tincanteksup wrote:
today I discovered that a server using TCP responds to an initial Syn
packet with an ack packet, even with --tls-auth key configured.
I presume this is expect
Hi,
On Wed, Feb 24, 2021 at 06:01:19PM +, tincanteksup wrote:
> today I discovered that a server using TCP responds to an initial Syn
> packet with an ack packet, even with --tls-auth key configured.
>
> I presume this is expected and cannot be avoided when using TCP due to
> initial IP req
Hi Marc,
thanks very much for the explanation.
I do understand the process but I also find this in the server log:
2021-02-24 18:29:27 us=920500 TCP connection established with
[AF_INET]127.0.0.1:42430
and this on the client:
nc -v 127.0.0.1 34571
Connection to 127.0.0.1 34571 port [tcp/*] su
On Wed, Feb 24, 2021 at 06:01:19PM +, tincanteksup wrote:
> today I discovered that a server using TCP responds to an initial Syn packet
> with an ack packet,
This is standard TCP protocol (SYN, SYN ACK, ACK). It is executed in the
kernel. Only after the client ACK is received by the server wi
Hi,
today I discovered that a server using TCP responds to an initial Syn
packet with an ack packet, even with --tls-auth key configured.
I presume this is expected and cannot be avoided when using TCP due to
initial IP requirements ?
Thanks
R
18 matches
Mail list logo
