Skynet Skynet logs of VPN(wireguard) clients

[peterpan]

Hello everyone,

I use Skynet and Wireguard. I checked if Skynet was properly working with Wireguard clients.
After some basic tests, I can confirm it is. Those tests were just trying to access Skynet blocked IPs, on specific ports, from a Wireguard connected client. I did this a couple of times with different IPs/ports. The traffic was indeed blocked, and Skynet seems to be working indeed for wireguard clients.

However, the logs show the blocked traffic in a way that is not that intuitive.
Skynet marks the blocked traffic as **INBOUND**. The source IP, is the malicious IP which the Wireguard client tried to access.
At first glance, this is misleading because it seems that the malicious IP tried to establish a connection to the router, which is not true. This is also reflected in the Skynet webUI statistics.

In the first screenshot, you see the IP of the Wireguard client, trying to access the malicious IP.

The router receives the Wireguard client request to *202.152.154.133:8080*, and that is further logged as if *202.152.154.133:8080* was trying to access my router, from the outside. Hence the **INBOUND** log by Skynet I guess.

In this 2nd screenshot, we see Skynet legitimately blocking the traffic, but marking it as **INBOUND**.

The hidden IP is my public IP.

Is there way this could be logged in a less misleading way ? For instance, it would be more clear if the IP of the Wireguard client would just appear under the *Top 10 Blocks (Outbound)* section of Skynet's webUI.

 

[L&LD]

Seems correct to me.

 

[peterpan]

Yes but, is there way to block outbound connections of the Wireguard clients as well? Given that Skynet is already configured to block both INBOUND and OUTBOUND traffic.

 

[dave14305]

Today, outbound blocking only applies to the LAN and OpenVPN servers’ clients. Wireguard isn’t supported yet, but on the radar.

IOT: Whitelist Wireguard by kevdliu · Pull Request #135 · Adamm00/IPSet_ASUS

The current iptables rules for IOT only whitelists openvpn (tun2+). This PR whitelists wireguard (wgs+) as well. The basic logic for the new rules is to accept all IOT traffic on tun2+, accept all ...

github.com

 

[peterpan]

Today, outbound blocking only applies to the LAN and OpenVPN servers’ clients. Wireguard isn’t supported yet, but on the radar.

IOT: Whitelist Wireguard by kevdliu · Pull Request #135 · Adamm00/IPSet_ASUS

The current iptables rules for IOT only whitelists openvpn (tun2+). This PR whitelists wireguard (wgs+) as well. The basic logic for the new rules is to accept all IOT traffic on tun2+, accept all ...

github.com

Thank you for pointing this out ! I will keep an eye on the updates.

The PR on GitHub only makes wireguard ignore IOT lists, along with openVPN. It is not full support.

 

[peterpan]

I don't know how to close this thread... Could some administrator please do it?

 

[L&LD]

What is the need to close this thread?

When new info is available, it can be added in that future timeframe.

 

[dave14305]

The PR on GitHub only makes wireguard ignore IOT lists, along with openVPN. It is not full support.

The interesting part is @Adamm planning “full Wireguard support” in the near future.

You can add a “Solved” prefix to the thread by using the “Edit thread” menu above the first post.

 

[peterpan]

What is the need to close this thread?

When new info is available, it can be added in that future timeframe.

Ok, I will keep it open. If I got aware of more information about this in the future, I will post it here.

 

[Adamm]

The interesting part is @Adamm planning “full Wireguard support” in the near future.

You can add a “Solved” prefix to the thread by using the “Edit thread” menu above the first post.

The work is already done, just didn’t want to release before the weekend as I’m in another city and if things go sideways I have limited access to push any fixes. Monday is a different story

 

[Kingp1n]

The work is already done, just didn’t want to release before the weekend as I’m in another city and if things go sideways I have limited access to push any fixes. Monday is a different story

@Adamm

Thank you for your continued support!!!

 

[Adamm]

These changes should now be live.

v7.5.4 · Adamm00/IPSet_ASUS@1ceb9c7

Create Generate_Random_Number() Improve Check_Connection() Fix syslog location showing as "custom" on newer models that default to jffs Add Wireguard server support - Wireguard server cli...

github.com

Let me know if it all works as expected.

 

[dave14305]

Let me know if it all works as expected.

“Log invalid” is broken because the existing logdrop rule is deleted before pos6 can be calculated. Or something close to that…some debug output before and after pos6 (It‘s empty).

Jan 22 14:54:24 Skynet: [i] Mounting Skynet Web Page As user2.asp
Jan 22 14:54:36 debug: Chain logdrop (10 references)
Jan 22 14:54:36 debug: num  target     prot opt source               destination         
Jan 22 14:54:36 debug: 1    DROP       all  --  0.0.0.0/0            0.0.0.0/0           
Jan 22 14:54:36 debug: pos6=

 

[peterpan]

These changes should now be live.

v7.5.4 · Adamm00/IPSet_ASUS@1ceb9c7

Create Generate_Random_Number() Improve Check_Connection() Fix syslog location showing as "custom" on newer models that default to jffs Add Wireguard server support - Wireguard server cli...

github.com

Let me know if it all works as expected.

I am currently facing some problems with my router and mesh repeaters and cannot even test this I will, as soon as I can. Hopefully in the next week/ two weeks.

Thanks for the updates !

 

[peterpan]

These changes should now be live.

v7.5.4 · Adamm00/IPSet_ASUS@1ceb9c7

Create Generate_Random_Number() Improve Check_Connection() Fix syslog location showing as "custom" on newer models that default to jffs Add Wireguard server support - Wireguard server cli...

github.com

Let me know if it all works as expected.

With the latest version of skynet, things did not change for me. I see logs similar to the ones in the description of the post.