Increase wireguard security udp port open|filtered / closed

Installing and Using OpenWrt
1

you can enable wireguard on a port that
appears to be closed for any port scans but allows the client to connect.
I would like to make for example that the port by performing a port scan results in this state:

nmap -sU my-ip -p 51820
51820 / udp closed unknown

instead of in this state:

nmap -sU my-ip -p 51820
51820 / udp open | filtered unknown

2

Yes, this is the design of Wireguard.

I don't understand your inquiry as Wireguard does not provide a response on a listening port unless you have the correct key/IP pairs. So the state that you wish to change is indicative of all UDP ports that are closed/not listened to.

:warning: You would have to BLOCK all traffic to 51820/udp...which means you also block valid Wireguard endpoint traffic.

I'm confused how you think this increases Wireguard security (given its design), perhaps you should take a look at: https://www.wireguard.com/protocol/#dos-mitigation

In fact, the server does not even respond at all to an unauthorized client; it is silent and invisible.

2 Likes
3

I'm currently testing inside a vlan where inbound traffic is reject.

of course I have to pre-force open the udp port where wireguard is listening,

i would like to know if in the future i should open a wan side udp port to allow access with wireguard if it is possible
leave the ability to access a client with the correct correct key / IP pairs but if someone interrogated the udp port the firewall could send the host a reject-with icmp-port-unreachable.

I thank you

4

Correct, which is why REJECT will not work after your ALLOW rule (i.e. you ALLOWed all traffic already).

This doesn't matter really, we're talking about the Wireguard interface which you seem able to reach.

...yes, WAN is just another VLAN.

Wireguard does not respond except to the correct key pairs; and it is a running process listening on the port (:spiral_notepad: perhaps that was forgotten).

So if ytou're saying that you want all 3:

  • ALLOW Wireguard via firewall
  • ALLOW valid WG endpoints
  • REJECT all others???

Perhaps we can get on page by clarifying this:

  1. How does the firewall know - if Wireguard must process and decrypt the packet first??? :bulb:
  2. How can the firewall tell that an invalid host doesn't possess a valid key before decryption by the Wireguard process??? :thinking:

Lastly, I'm not understanding how making a silent port respond with an ICMP Unreachable message - makes it more secure?

2 Likes
5

I thought you set an iptables rule that duplicates the input package for the UDP port and simultaneously responds with a reject-with ICMP Port Unreachable and in any case forward traffic to the correct door where Wireguard is listening.

In such a way that any access attempts towards that port are rejected, but the clients in possession of the correct configuration can log in.

I know that wireguard automatically does not send traffic if there is no proper handshake.

I apologize if the questions I am doing seem stupid, partly depends on the automatic translator

thanks that interest

1 Like
6

how? the access attempt is rejected, you said so yourself - you can't reject a connection, then subsequently accept it

I fail to see how responding to a packet in any way from an invalid host is more secure than ignoring it

2 Likes
7

Hummm....if even possible...you desire to return an ICMP-Unreachable message to all senders:

  1. :white_check_mark: If valid, you tell the IP Stack on the far end to stop :stop_sign: - you don't want this
  2. :x: If a malicious host, you tell them that there's a device responding to traffic - not secure

With that said...it may be possible to make a custom chain where you send the ICMP message and return the packet back to the main chain...but I've never tested such a firewall rule.

Lastly, you'd have to block that ICMP message on the SRC networks of all valid clients...and that is likely impossible

3 Likes
8

ok

I will consider another system to make access more secure,
I assume I will opt for "Port knocking server knockd"

but the package:

is not available in the package list by running:

opkg update

thanks for the help

1 Like
9

Why do you think it needs to be more secure than how it already operates? Or how do you think your planned outcome will make it more secure?

3 Likes
10

As both @lleachii and @krazeh have already said, WG is secure already, and your desire to further secure it is both pointless and counterproductive.

I'll repeat what has already been said, but maybe slightly differently.

  • UDP, by nature and design, does not require any ack packets -- this is a key difference from TCP.
  • Wireguard itself is not 'chatty' -- it does not send any reply at all if the remote peer does not have proper cryptographic keys.
  • Because Wireguard uses UDP, a remote system that sends a packet will not get any response whatsoever if the remote peer isn't valid per above.
  • A port scan on a port that is using Wireguard (in any normal installation) will result in what is sometimes called a 'stealth' result, which is to say that it doesn't respond. There is no indication that there is anything on the other end. (Port scans can report ports as open, closed/rejected, or stealth/no-response).

If you think about this 'stealth' result vs one that actively sends a 'reject' response, the more secure is the no-answer situation because it reveals nothing at all. You can compare it to answering the phone and saying "go away" vs not answering at all... if you answer, the caller knows that you're there, but if you don't answer at all, they have no idea if your number works at all.

3 Likes
11

I don't think UDP ever gets this status - in my testing (with nmap), it's either

  • closed - when the firewall is set to reject
  • open|filtered - when the firewall is set to deny
  • open|filtered - when the firewall is set to accept

Regardless if anything is actually listening on the port or not

1 Like
12

thank you all for the answers provided

13

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.