Community discussions

MikroTik App
 
TaxiPieter
just joined
Topic Author
Posts: 8
Joined: Mon Aug 03, 2009 9:43 pm
Location: Merksem, Belgium

Flooding UDP port 1194

Fri May 22, 2020 8:20 pm

Help! My openVPN server is under attack..
I already was able to stop 90% of the traffic if they origin from a different port with the following rules:

/ip firewall filter
add action=add-src-to-address-list address-list=blocked-addr address-list-timeout=1d chain=forward connection-limit=2,32 dst-port=1194 \
log-prefix=Blocked protocol=udp
add action=drop chain=forward src-address-list=blocked-addr

Then my log looks like this:
May 22 19:15:52 IOT logger [VPN2/VPN] (2020-05-22 19:15:53.765) <SERVER_LOG>: OpenVPN Session 9769670 (91.39.182.4:2742 -> 192.168.1.103:1194): A new session is created. Protocol: UDP
May 22 19:15:52 IOT logger [VPN2/VPN] (2020-05-22 19:15:53.766) <SERVER_LOG>: OpenVPN Session 9769670 (91.39.182.4:2742 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 19:15:52 IOT logger [VPN2/VPN] (2020-05-22 19:15:53.767) <SERVER_LOG>: OpenVPN Session 9769671 (91.39.182.4:51249 -> 192.168.1.103:1194): A new session is created. Protocol: UDP
May 22 19:15:52 IOT logger [VPN2/VPN] (2020-05-22 19:15:53.767) <SERVER_LOG>: OpenVPN Session 9769671 (91.39.182.4:51249 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 19:16:23 IOT logger [VPN2/VPN] (2020-05-22 19:16:23.835) <SERVER_LOG>: OpenVPN Session 9769670 (91.39.182.4:2742 -> 192.168.1.103:1194): Deleting the session.
May 22 19:16:23 IOT logger [VPN2/VPN] (2020-05-22 19:16:23.835) <SERVER_LOG>: OpenVPN Session 9769671 (91.39.182.4:51249 -> 192.168.1.103:1194): Deleting the session.

So after 2 attempts they are blocked.
But the problem is when the source port is the same, nothing is stopped at all.

May 22 18:54:09 IOT logger [VPN2/VPN] (2020-05-22 18:54:09.879) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:09 IOT logger [VPN2/VPN] (2020-05-22 18:54:10.065) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:09 IOT logger [VPN2/VPN] (2020-05-22 18:54:10.194) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:09 IOT logger [VPN2/VPN] (2020-05-22 18:54:10.335) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:09 IOT logger [VPN2/VPN] (2020-05-22 18:54:10.337) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:09 IOT logger [VPN2/VPN] (2020-05-22 18:54:10.357) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:09 IOT logger [VPN2/VPN] (2020-05-22 18:54:10.506) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:09 IOT logger [VPN2/VPN] (2020-05-22 18:54:10.650) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:09 IOT logger [VPN2/VPN] (2020-05-22 18:54:10.718) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:09 IOT logger [VPN2/VPN] (2020-05-22 18:54:10.720) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:10 IOT logger [VPN2/VPN] (2020-05-22 18:54:10.814) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:10 IOT logger [VPN2/VPN] (2020-05-22 18:54:10.943) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:10 IOT logger [VPN2/VPN] (2020-05-22 18:54:11.046) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:10 IOT logger [VPN2/VPN] (2020-05-22 18:54:11.047) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:10 IOT logger [VPN2/VPN] (2020-05-22 18:54:11.113) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:10 IOT logger [VPN2/VPN] (2020-05-22 18:54:11.236) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:10 IOT logger [VPN2/VPN] (2020-05-22 18:54:11.376) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:10 IOT logger [VPN2/VPN] (2020-05-22 18:54:11.377) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:10 IOT logger [VPN2/VPN] (2020-05-22 18:54:11.415) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:10 IOT logger [VPN2/VPN] (2020-05-22 18:54:11.529) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:10 IOT logger [VPN2/VPN] (2020-05-22 18:54:11.698) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:10 IOT logger [VPN2/VPN] (2020-05-22 18:54:11.699) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:10 IOT logger [VPN2/VPN] (2020-05-22 18:54:11.715) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:11 IOT logger [VPN2/VPN] (2020-05-22 18:54:11.821) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:11 IOT logger [VPN2/VPN] (2020-05-22 18:54:12.015) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:11 IOT logger [VPN2/VPN] (2020-05-22 18:54:12.025) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:11 IOT logger [VPN2/VPN] (2020-05-22 18:54:12.026) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:11 IOT logger [VPN2/VPN] (2020-05-22 18:54:12.113) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:11 IOT logger [VPN2/VPN] (2020-05-22 18:54:12.315) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:11 IOT logger [VPN2/VPN] (2020-05-22 18:54:12.359) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:11 IOT logger [VPN2/VPN] (2020-05-22 18:54:12.360) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:11 IOT logger [VPN2/VPN] (2020-05-22 18:54:12.404) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:11 IOT logger [VPN2/VPN] (2020-05-22 18:54:12.612) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:11 IOT logger [VPN2/VPN] (2020-05-22 18:54:12.686) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:11 IOT logger [VPN2/VPN] (2020-05-22 18:54:12.687) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.
May 22 18:54:11 IOT logger [VPN2/VPN] (2020-05-22 18:54:12.696) <SERVER_LOG>: OpenVPN Session 9769665 (78.95.209.40:2112 -> 192.168.1.103:1194) Channel 0: A new channel is created.

And so on..
Can anyone help me with the correct firewall rule? Many thanks!
 
msatter
Forum Guru
Forum Guru
Posts: 1633
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: Flooding UDP port 1194

Fri May 22, 2020 9:22 pm

They are sending it now as a stream so it seems not to be closed.

Try this in RAW and see if that stops the attacks:
psd (integer,time,integer,integer; Default: ) 	Attempts to detect TCP and UDP scans. Parameters are in following format WeightThreshold, DelayThreshold, LowPortWeight, HighPortWeight

    WeightThreshold - total weight of the latest TCP/UDP packets with different destination ports coming from the same host to be treated as port scan sequence
    DelayThreshold - delay for the packets with different destination ports coming from the same host to be treated as possible port scan subsequence
    LowPortWeight - weight of the packets with privileged (<1024) destination port
    HighPortWeight - weight of the packet with non-priviliged destination port 
One RB4011 (cooled) and a RB760iGS (hEX S) in series. 4011 Does PPPoE/IKEv2.
Running:
RouterOS 6.47 / Winbox 3.24 / MikroTik APP 1.3.12
NordVPN viewtopic.php?f=2&t=158439&p=781009 for multiple connections.
 
EnigmAX
just joined
Posts: 11
Joined: Tue May 20, 2014 9:49 pm

Re: Flooding UDP port 1194

Fri May 22, 2020 9:27 pm

Check out this (old) piece of information, and focus on the content of a "failed login" with openvpn:

https://wiki.mikrotik.com/wiki/Brutefor ... prevention
 
TaxiPieter
just joined
Topic Author
Posts: 8
Joined: Mon Aug 03, 2009 9:43 pm
Location: Merksem, Belgium

Re: Flooding UDP port 1194

Fri May 22, 2020 9:29 pm

They are sending it now as a stream so it seems not to be closed.

Try this in RAW and see if that stops the attacks:
psd (integer,time,integer,integer; Default: ) 	Attempts to detect TCP and UDP scans. Parameters are in following format WeightThreshold, DelayThreshold, LowPortWeight, HighPortWeight

    WeightThreshold - total weight of the latest TCP/UDP packets with different destination ports coming from the same host to be treated as port scan sequence
    DelayThreshold - delay for the packets with different destination ports coming from the same host to be treated as possible port scan subsequence
    LowPortWeight - weight of the packets with privileged (<1024) destination port
    HighPortWeight - weight of the packet with non-priviliged destination port 
A port scanner was actually alreadt active in the firewall / filter:

add action=add-src-to-address-list address-list=blocked-addr address-list-timeout=1w chain=input comment="Port Scanner Detect" protocol=tcp psd=\
21,3s,3,1

So far it blocked 1 ip-address..
 
TaxiPieter
just joined
Topic Author
Posts: 8
Joined: Mon Aug 03, 2009 9:43 pm
Location: Merksem, Belgium

Re: Flooding UDP port 1194

Fri May 22, 2020 9:33 pm

I still want users with a valid certificate to connect, so just closing port 1194 is not really an option. Moving to port 1196 for example is just a matter of time..
 
User avatar
jvanhambelgium
Member Candidate
Member Candidate
Posts: 218
Joined: Thu Jul 14, 2016 9:29 pm
Location: Belgium

Re: Flooding UDP port 1194

Fri May 22, 2020 9:34 pm

Problem is the source IP + source port remain the same.
Don't think the PSD attributed are going to be very useful here...they operate on the DESTINATION PORT and (same) SOURCE-IP but does not look at the SRC-PORT of the SOURCE-IP.

If your OpenVPN needs to be really .... open and globally accessible I think the options are limited ....
Ask yourself : Does the whole world need potential access to it ? If you live in country X why not limit access to IP's of country X .... I don't know your exact use-case for OpenVPN.
 
TaxiPieter
just joined
Topic Author
Posts: 8
Joined: Mon Aug 03, 2009 9:43 pm
Location: Merksem, Belgium

Re: Flooding UDP port 1194

Fri May 22, 2020 9:38 pm

Problem is the source IP + source port remain the same.
Don't think the PSD attributed are going to be very useful here...they operate on the DESTINATION PORT and (same) SOURCE-IP but does not look at the SRC-PORT of the SOURCE-IP.

If your OpenVPN needs to be really .... open and globally accessible I think the options are limited ....
Ask yourself : Does the whole world need potential access to it ? If you live in country X why not limit access to IP's of country X .... I don't know your exact use-case for OpenVPN.
Hey.. Actually, yes, all over the world. Users connecting to my VPN can watch Yelo TV outside Europe..
I have customers in Dubai, Thailand, USA and few other countries..
 
User avatar
jvanhambelgium
Member Candidate
Member Candidate
Posts: 218
Joined: Thu Jul 14, 2016 9:29 pm
Location: Belgium

Re: Flooding UDP port 1194

Fri May 22, 2020 9:38 pm

I still want users with a valid certificate to connect, so just closing port 1194 is not really an option. Moving to port 1196 for example is just a matter of time..
That is the issue with running a full public service...
Off course I don't know your userbase, but perhaps a script before the connection could be launch to trigger a port-knock sequence effectively open up OpenVPN ports...however you need to discuss with your users.
I don't know who managed the clients, on which platforms they run etc,etc.
 
TaxiPieter
just joined
Topic Author
Posts: 8
Joined: Mon Aug 03, 2009 9:43 pm
Location: Merksem, Belgium

Re: Flooding UDP port 1194

Fri May 22, 2020 9:44 pm

I still want users with a valid certificate to connect, so just closing port 1194 is not really an option. Moving to port 1196 for example is just a matter of time..
That is the issue with running a full public service...
Off course I don't know your userbase, but perhaps a script before the connection could be launch to trigger a port-knock sequence effectively open up OpenVPN ports...however you need to discuss with your users.
I don't know who managed the clients, on which platforms they run etc,etc.
That's the point why I use OpenVPN. My customers aren't that computer-minded, so importing a certificate, inputting username and password is just doable for them. If i talk them about port-knocking they probably go knock on their own 'gate'.
So what you're saying is: deal with it, not really a solution?

They run on Windows, IOS, Mac, Android..
 
User avatar
jvanhambelgium
Member Candidate
Member Candidate
Posts: 218
Joined: Thu Jul 14, 2016 9:29 pm
Location: Belgium

Re: Flooding UDP port 1194

Fri May 22, 2020 9:46 pm

Problem is the source IP + source port remain the same.
Don't think the PSD attributed are going to be very useful here...they operate on the DESTINATION PORT and (same) SOURCE-IP but does not look at the SRC-PORT of the SOURCE-IP.

If your OpenVPN needs to be really .... open and globally accessible I think the options are limited ....
Ask yourself : Does the whole world need potential access to it ? If you live in country X why not limit access to IP's of country X .... I don't know your exact use-case for OpenVPN.
Hey.. Actually, yes, all over the world. Users connecting to my VPN can watch Yelo TV outside Europe..
I have customers in Dubai, Thailand, USA and few other countries..
Ah OK, a (semi) illegal service then since I don't think Telenet allows this ;-)
There is a reason why this (live) content-viewing is limited within EU...

Anyway for your problem I think you just need to deal with it

1) Invest time to scan the logs regularly, do some parsing and add the annoying guys onto the block-list anyway and hope it goes away quickly.
2) If your backend systems/OpenVPN gateway are sized appropriately it will handle it and not get stressed out by these (few) attempts.

The IP spamming you is registered Saudi Telecom apparently...

Perhaps the solution given earlier might help ? The section on SSH-brute force.

If you construct something like that...normally a GOOD user makes an inbound connection (incoming SYN) only once basically. So with a multi-stage filter you can throw the IP's on the list that make 3 attempts or something. Only the "state" is evaluated and normally from the same IP you don't want to see 3 SYN's coming in.
But perhaps you should take a capture to have slighty more details on what they are injecting, but I suppose at TCP-level the 3-way handshake works because I seen the OpenVPN service create some channel?

https://wiki.mikrotik.com/wiki/Brutefor ... prevention
Last edited by jvanhambelgium on Fri May 22, 2020 9:57 pm, edited 1 time in total.
 
TaxiPieter
just joined
Topic Author
Posts: 8
Joined: Mon Aug 03, 2009 9:43 pm
Location: Merksem, Belgium

Re: Flooding UDP port 1194

Fri May 22, 2020 9:54 pm

Problem is the source IP + source port remain the same.
Don't think the PSD attributed are going to be very useful here...they operate on the DESTINATION PORT and (same) SOURCE-IP but does not look at the SRC-PORT of the SOURCE-IP.

If your OpenVPN needs to be really .... open and globally accessible I think the options are limited ....
Ask yourself : Does the whole world need potential access to it ? If you live in country X why not limit access to IP's of country X .... I don't know your exact use-case for OpenVPN.
Hey.. Actually, yes, all over the world. Users connecting to my VPN can watch Yelo TV outside Europe..
I have customers in Dubai, Thailand, USA and few other countries..
Ah OK, a (semi) illegal service then since I don't think Telenet allows this ;-)
There is a reason why this (live) content-viewing is limited within EU...

Anyway for your problem I think you just need to deal with it

1) Invest time to scan the logs regularly, do some parsing and add the annoying guys onto the block-list anyway and hope it goes away quickly.
2) If your backend systems/OpenVPN gateway are sized appropriately it will handle it and not get stressed out by these (few) attempts.

The IP spamming you is registered Saudi Telecom apparently...
They're Belgian citizens with a valid telenet login..
The annoying guys are automatically put on a blacklist and blocked.. That stops about 90% (316 different IP's in 24h) The only difficutly I'm facing now is when the originating port is the same, then they can have indefinite attempts. It's not stressed, nobody complaining about poor quality..
Yes, i already traced some of the IP's. The Saudi's and the Russians are very active.. If of course, the IP's are not spoofed..
 
anav
Forum Guru
Forum Guru
Posts: 4261
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Flooding UDP port 1194

Fri May 22, 2020 10:05 pm

Why not change the port (port translation in router) to your customers. like use 54332
dydns name/url:54332

add chain=dstnat action=dst-nat in-interface-list=WAN dst-port=54332 protocol=tcp? to-addresses=IPserver to-ports=1194

Why would udp scans be stopped by a TCP rule (title of thread- "FLOODING UDP")??
"A port scanner was actually alreadt active in the firewall / filter:
add action=add-src-to-address-list address-list=blocked-addr address-list-timeout=1w chain=input comment="Port Scanner Detect" protocol=tcp psd=\
21,3s,3,1
So far it blocked 1 ip-address..
"e
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
TaxiPieter
just joined
Topic Author
Posts: 8
Joined: Mon Aug 03, 2009 9:43 pm
Location: Merksem, Belgium

Re: Flooding UDP port 1194

Sat May 23, 2020 12:19 pm

Why not change the port (port translation in router) to your customers. like use 54332
dydns name/url:54332

add chain=dstnat action=dst-nat in-interface-list=WAN dst-port=54332 protocol=tcp? to-addresses=IPserver to-ports=1194

Why would udp scans be stopped by a TCP rule (title of thread- "FLOODING UDP")??
"A port scanner was actually alreadt active in the firewall / filter:
add action=add-src-to-address-list address-list=blocked-addr address-list-timeout=1w chain=input comment="Port Scanner Detect" protocol=tcp psd=\
21,3s,3,1
So far it blocked 1 ip-address..
"e
Thanks, I'll have a look into that. The firewall rule for UDP scans is added too. Thanks for the suggestion..
 
User avatar
jvanhambelgium
Member Candidate
Member Candidate
Posts: 218
Joined: Thu Jul 14, 2016 9:29 pm
Location: Belgium

Re: Flooding UDP port 1194

Sat May 23, 2020 12:32 pm

Why not change the port (port translation in router) to your customers. like use 54332
dydns name/url:54332

add chain=dstnat action=dst-nat in-interface-list=WAN dst-port=54332 protocol=tcp? to-addresses=IPserver to-ports=1194

Why would udp scans be stopped by a TCP rule (title of thread- "FLOODING UDP")??
"A port scanner was actually alreadt active in the firewall / filter:
add action=add-src-to-address-list address-list=blocked-addr address-list-timeout=1w chain=input comment="Port Scanner Detect" protocol=tcp psd=\
21,3s,3,1
So far it blocked 1 ip-address..
"e
Thanks, I'll have a look into that. The firewall rule for UDP scans is added too. Thanks for the suggestion..
Perhaps you should review your "psd" attributes, by default they are 21,3s,3,1 but they need tuning
I would evaluate over a larger time-window.
I evaluate over the span of multiple hours, my "total weight" (default 21) has been brought down also and then weight for low-ports-hits (3) and high-port-hits (1) also adjusted.
total weight = amount of hits x weight-per-type.
You can play with that.

Eg.
Time-Window = 04:00:00 (= evaluate over 4 hours)
Weigh-total = 15
Low-ports = 3
High-ports = 1

This means over a span of 4 hours, the "attacker" would be allowed to fire 6 packets targeted at a low port (< 1024) because then he reaches 6 x 3 = 18 and this exceeds the total-weight 15 threshold.
Similar an attacker could fire 16 packets at a high-port, so 16 x 1 = 16 and also exceeds total-weight of 15.
See?
 
User avatar
mutluit
Long time Member
Long time Member
Posts: 505
Joined: Wed Mar 25, 2020 4:04 am

Re: Flooding UDP port 1194

Sat May 23, 2020 1:50 pm

@TaxiPieter, your method is doomed to fail.
If your VPN server is on a server or serverPC, then you better should install a tool like fail2ban on that server. See https://en.wikipedia.org/wiki/Fail2ban

And: just remove UDP from VPN, ie. allow only TCP connections... See also https://proprivacy.com/vpn/guides/openv ... nce-choose
If you want your OpenVPN server to listen on a TCP port instead of a UDP port, use proto tcp instead of proto udp in its config file.
Then you can block incoming traffic to the UDP port 1194 completely.

Who is online

Users browsing this forum: alexanwar, Maggiore81, td32 and 118 guests