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/*] succeeded!
which suggested to me that openvpn may have some vulnerability to TCP DDos.
Obviously, the connection ultimately fails but I was simply expecting
the server to drop the subsequent packets without logging anything.
Especially as both server and client believe that TCP has established a
connection, even to the extent of:
ESTAB 0 0
127.0.0.1:34571 127.0.0.1:42714
ESTAB 0 0
127.0.0.1:42714 127.0.0.1:34571
In the case of TCP, this obviously cannot be avoided because the kernel
manages the initial handshake and then openvpn takes over and
establishes TLS.
I wonder if IPv6 has any new features which can customise the initial
Syn packet in any way ?
I doubt it but something for me to look into ;-)
Regards
On 24/02/2021 18:11, Marc SCHAEFER wrote:
On Wed, Feb 24, 2021 at 06:01:19PM +0000, 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 will
OpenVPN handle that TCP connection (accept(2) returns a new connection
socked in the ESTABLISHED state).
Before that, OpenVPN does not even know a connection is being opened.
even with --tls-auth key configured.
This, TCP does not know. For TCP, it's just data bytes.
The TLS negociation is done afterwards, when the TCP connection was
established.
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
