Connection from unkown IP (internettl.org?)

[TinCanTech]

Hey, what's going on here?!!!
You posted my message...

You are the mod and you obviously edited my message rather than posting your own .. accidentally

Will look tomorrow and contact via irc, hhave to leave because of curfew

What? Curfew ? .. I thought you guys had rejected the curfew .. I certainly have!

[Endstille]

(((ps. does this mean something is up? Ö)))

Edit, the same IP "connected" again about 45 mins ago (just mentioning, not sure if it is useful since it's no new info):

Wed Feb 24 20:34:24 2021 MULTI: multi_create_instance called
Wed Feb 24 20:34:24 2021 Re-using SSL/TLS context
Wed Feb 24 20:34:24 2021 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Wed Feb 24 20:34:24 2021 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Wed Feb 24 20:34:24 2021 Control Channel MTU parms [ ~ ]
Wed Feb 24 20:34:24 2021 Data Channel MTU parms [ ~ ]
Wed Feb 24 20:34:24 2021 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1551,tun-mtu 1500,proto TCPv4_SERVER,keydir 0,cipher AES-256-GCM,auth [null-digest],keysize 256,tls-auth,key-method 2,tls-server'
Wed Feb 24 20:34:24 2021 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1551,tun-mtu 1500,proto TCPv4_CLIENT,keydir 1,cipher AES-256-GCM,auth [null-digest],keysize 256,tls-auth,key-method 2,tls-client'
Wed Feb 24 20:34:24 2021 TCP connection established with [AF_INET]185.156.72.6:64895
Wed Feb 24 20:34:24 2021 Socket flags: TCP_NODELAY=1 succeeded
Wed Feb 24 20:34:24 2021 TCPv4_SERVER link local: (not bound)
Wed Feb 24 20:34:24 2021 TCPv4_SERVER link remote: [AF_INET]185.156.72.6:64895
Wed Feb 24 20:35:24 2021 185.156.72.6:64895 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Feb 24 20:35:24 2021 185.156.72.6:64895 TLS Error: TLS handshake failed
Wed Feb 24 20:35:24 2021 185.156.72.6:64895 Fatal TLS error (check_tls_errors_co), restarting
Wed Feb 24 20:35:24 2021 185.156.72.6:64895 SIGUSR1[soft,tls-error] received, client-instance restarting
Wed Feb 24 20:35:24 2021 TCP/UDP: Closing socket

[TinCanTech]

Don't worry about it. OpenVPN has not leaked any data and the scanner in question is not malicious.

This spawned a small discussion on the mailing list which you can read here:
https://sourceforge.net/p/openvpn/mailm ... sg37226908
and
https://sourceforge.net/p/openvpn/mailm ... sg37226875

[Endstille]

Allright, cool! So, as far as I understand it, it's just the connection-oriented nature of TCP, correct? A connection is established since that's how TCP works, then the authorization is initialized but the client can't verify his nature (since he doesn't have the dh parameters etc.) so he's kicked out.

In some way, that is a comforting thing to know but in another way it's still a connection and i'm not tech savvy enough feel comfortable about that/to know what can be done with that connection

I'll read up about the prevention measurements that were suggested (SYN cookies & intrusion detection/prevention system) and look around for some viable options (free & "trustable" ). The current router I have is a simple ISP router but none of the other devices at home run services on the port i'm using for OpenVPN (except OpenVPN it'self but that won't be used at home) so currently i'll just look for a server-only implementation.

Again, thank you all for your inputs!

[Endstille]

Quick note; i followed up the mailing list up until now (going to bed in 5 mins) but I may have a suggestion (even though i'm not sure if i'm on the same line as you guys). Would it be an option to implement the error handling and flow control functions of TCP (sequence nr, ack number, window size, checksum, etc...) in the OpenVPN software so that UDP can be used with the same reliability as TCP? This would make it possible to dodge a special implementation of the SYN/SYNACK/ACK process and the server would also not aknowledge that it is running a service on the used port.

I'm way behind you guys in terms of... everything but appreciate the efforts so i thought putting my brainmatter to work is the least i could do (even though i have no clue if this is a viable option).

[Endstille]

Ok I can't fall asleep. In the meantime i found this: https://openvpn.net/faq/what-is-tcp-meltdown/

Which mentions: "TCP Meltdown occurs when you stack one transmission protocol on top of another, like what happens when an OpenVPN TCP tunnel is transporting TCP traffic inside it."

Does this also mean that any TCP based protocol (e.g. SMB shares) can pass along an UDP tunnel and still ''be fine'' if packets are received out of order? (Data integrity is the reason I went straight for the TCP protocol with the OVPN server).

Thanks again and goodnight!

[TinCanTech]

as far as I understand it, it's just the connection-oriented nature of TCP, correct?

Yep.

then the authorization is initialized but the client can't verify his nature (since he doesn't have the dh parameters etc.) so he's kicked out.

Not sure I understand you ..

How openvpn verifies a client has nothing to do with the TCP layer, which is the discussion here.

In some way, that is a comforting thing to know but in another way it's still a connection and i'm not tech savvy enough feel comfortable about that/to know what can be done with that connection

You have nothing to fear.

The Linux kernel is Open source and peer reviewed. And then it has to provide the internet at large a working system. And that system is tested daily by gazillions of network transactions. It's quite good at it ..

If you are concerned then the simple answer is to use UDP. It is unlikely that TCP is giving you any real benefit and that is why UDP is the default.

Would it be an option to implement the error handling and flow control functions of TCP (sequence nr, ack number, window size, checksum, etc...) in the OpenVPN software so that UDP can be used with the same reliability as TCP?

Openvpn does this for you as it stands. Although, not in the way you are thinking.

This would make it possible to dodge a special implementation of the SYN/SYNACK/ACK process and the server would also not aknowledge that it is running a service on the used port.

I suggested exactly this on the mailing list but, again, not as you describe.

Changing TCP protocol to support TCP Fast Open allows for data to be sent in the SYN packet.
TCP already allows data in the SYN packet but it has never been used by the internet at large.
Allowing data in a SYN packet is largely banned by firewalls because it is deemed to be an attack of some sort.
However, TFO began back in 2010 (or earlier) and by now firewalls are probably more likely to have a knob to twiddle to allow this traffic.
TFO still requires the initial three-way-handshake to complete at least once.
As I understand it, the of cookie of a TFO SYN-COOKIE packet is still only handled by the kernel (i think).

My idea was to take that a step further and pass the cookie data directly and immediately to the application and for the kernel to wait for the application to respond. That is miles outside the scope of TFO but it was TFO that spawned the idea.

Does this also mean that any TCP based protocol (e.g. SMB shares) can pass along an UDP tunnel and still ''be fine'' if packets are received out of order?

Of course. The internet would be out-of-business if it were not so ..

TCP Meltdown occurs when you stack one transmission protocol on top of another, like what happens when an OpenVPN TCP tunnel is transporting TCP traffic inside it

It is exactly like Feedback when you put an electric guitar to close to the speakers

[TinCanTech]

Things move fast on the internet: https://squeeze.isobar.com/2019/04/11/t ... fast-open/

[Endstille]

Hello again,

Sorry for the late answer, I've had a few busy days! I've been using udp for the last 24-36 hours and everything is working as it should; no unknown IP's established connections and file syncing (e.g. syncthing) seems to be reliable!

Thank you again for all the feedback/help and maybe we'll see eachother again in the future!

[artembrones]

If you configure TLS-auth correctly then you should never see those connection attempts because openvpn will simply drop the packet.

[TinCanTech]

If you configure TLS-auth correctly then you should never see those connection attempts

Pray tell ..

[artembrones]

Not many can boast of a decent kind of earnings on the Internet because you need to have a certain specialty that would chop babosiky. And those who have no experience or profession remains to do small jobs. But there is a service like this to unlock the captcha https://2captcha.com/ simple job, but you can make $ 5 a day quietly.

[TinCanTech]

Everything you just said ..

Therefore,

Please explain.

[tamalpais]

I'm a new openvpn user & also started a new service with Spectrum & saw your post when searching on internettl.org or rethem hosting - I'm trying to find out what I can about this org that attacks my home router every week & they have no contact available. For what it's worth their range used to attack is 104.152.52.90 - 104.152.52.250 also maybe a wider range, Spectrum wont listen to my requests to block Rethem from their network

For reference: https://www.abuseipdb.com/check/104.152.52.213

Their upstream host is gtt.net & I've talked to them but they wont acknowledge their "customer"

customer of gtt.net - traceroute:
GTT.net as14987.xe-3-0-0.ar1.ord6.us.as4436.gtt.net 69.31.110.70
Rethem Hosting internettl.org 104.152.52.213