ACL Rule Mfa always has precedence over Allow? #43
Comments
|
Hi there! This is totally an edge case I didnt consider when designing and building Wag. My only issue here is that the However, the use case you're describing should still be viable. Im going to have a little think about how to solve this, as there really isnt an immediately obvious tidy way to do this. |
|
Thank you NHAS. |
|
Okay, so what I am planning on doing to resolve this edge case it to move from using MFA precedence to most specific route match precedence. e.g if you have an MFA selector for Little bit worried about how intuitive that is and if it provides enough protection against foot guns. It may also weaken existing deployments people have. However I dont see any other way of accomplishing this goal, and its something that should exist. |
On a side note, this cant be integrated with the GUI client as its effectively all server side. |
NHAS
changed the title
Thank you NHAS! |
Thank you for the reply. What I meant is to have the MFA code web page integrated to the Wireguard Windows/macOS/IOS/Andriod GUI client. The GUI client will open up the http://wg_server_tunnel_IP:8080 webpage in the default browser for the user to enter the MFA code after he clicks Activate. The client conf file will contain info on whether MFA is needed and the URL of the MFA website. Thank you for coming out with this wonderful software. The lack of MFA in Wireguard was a showstopper for using it in enterprises. WAG could change this and WG with WAG could overtake OpenVPN because Wireguard is much faster than OpenVPN. |
Funny enough the way the longest prefix matching trie structure works there isn't a particularly elegant way of representing this in the code. As that's the only structure the kernel provides to ebpf programs that can do subnet matching we have to stick to it as well. |
|
This is now on unstable, after I've knock off some other issues I'll be doing a v6.x.x release to bring this to wag. Thanks for your feedback! |
|
Thank you NHAS! Will give it a try. Wishing you great success with this project. |
|
Tested 6.0.1 pre-release. It doesn't seem to work. Tried three config.json's. Thank you very much. _________________________________________- ====== ====================== |
|
Hm. I see the issue, I've added a check to make sure people can't add duplicate routes (as they get overwritten so effectively only the last route is ever used for a specific route) However I've implemented it poorly and it doesn't take into account some basic side cases. That last configuration file should be working. |
|
Actually that last config could be because the server automatically adds an allow route for itself. |
NHAS
changed the title
|
I've updated the release to remove duplicate route detection. I'll add it back in later when I have half a mind to design it right. https://github.com/NHAS/wag/releases/tag/v6.1.1-pre-release |
NHAS
added
the
needs testing (on unstable)
|
Yes, tested 6.0.1 and it works when the ""Allow": ["10.125.0.1/32"]" is removed. So the server IP is automatically allowed and on all ports? What if we only want to allow 8080/any? Thank you very much. |
|
For the moment. Just ignore 6.0.1, try the new release, I've removed the restriction. |
6.1.1 does not work. Not able to access the MFA 10.125.0.0/16 network like before. Tested config below with 6.1.1. Cannot access 10.125.0.0/16. Thank you. "Policies": {
"*": {
"Allow": [
"10.125.0.1/32 8080/any"
]
},
"group:users": {
"Allow": [
"10.125.0.1/32 8080/any"
],
"Mfa": [
"10.125.0.0/16",
"192.168.5.0/24",
"192.168.6.0/24"
]
},
"group:administrators": {
"Allow": [
"10.125.0.0/16",
"192.168.5.0/24",
"192.168.6.0/24"
]
}
}
} |
|
Im going to need more information about your user groups. As if your user is just in |
|
I can confirm the following works for me: "Policies": {
"*": {
"Mfa": [
"142.250.67.14/32",
"1.1.0.0/16"
]
},
"group:toast": {
"Allow": [
"1.1.1.1"
],
"Mfa": [
"4.4.4.4 123/tcp",
"5.5.5.5"
]
}
} |
6.0.1 works in that we can access the MFA 10.125.0.0/16 (the VPN tunnel network) after going to the server ip:8080 to enter the MFA code (provided we remove the allow server IP - since you mentioned it is automatically allowed in 6.0.1). In 6.1.1, we were able to go to 10.125.0.1:8080 to enter the MFA code. But after that, we can only go to the MFA 192.168.5.0/24 and 192.168.6.0/24 but not the MFA VPN tunnel network 10.125.0.0/16. Note I only have one client and so I tested ping 10.125.0.1 and it didn't work in 6.1.1 (works in 6.0.1 - can also ssh 10.125.0.1 in 6.0.1). It can of course ping itself 10.125.0.3 (the client VPN tunnel interface IP). "group:users": {
"Allow": [
"10.125.0.1/32 8080/any"
],
"Mfa": [
"10.125.0.0/16",
"192.168.5.0/24",
"192.168.6.0/24"
]
}, |
|
Sure you may have one user, but I need to know what group that user is in. Hence Im struggling to understand how this could be an issue. |
The difference with between our configs is we don't have the "Mfa VPN tunnel network" in the "*" group like yours ( "Mfa": ["142.250.67.14/32","1.1.0.0/16"]). Our ""Mfa": [ "10.125.0.0/16"," is in the group.users. |
The user is in the "group:users" group. Thank you. |
Im not really sure what you mean by this. If you can hit the server address, then this is working, you said you only have one device in the VPN network so you're not going to be able to hit anything else? This may also be an iptables issue? Can you give me the command you're using, what you're trying to ping, etc? |
|
Can you give me your whole configuration file (minus the private key) I'll just run this straight and see if I can replicate. |
It is not Iptables issue if we can hit the MFA 10.125.0.0/16 (VPN tunnel) network with 6.0.1. |
|
Have you reverted to 6.0.1 to try it? |
{
"Lockout": 5,
"HelpMail": "[email protected]",
"MaxSessionLifetimeMinutes": 7200,
"SessionInactivityTimeoutMinutes": 1440,
"ExternalAddress": "pawg.example.com",
"DatabaseLocation": "devices.db",
"Socket": "/tmp/wag.sock",
"Webserver": {
"Public": {
"ListenAddress": "192.168.5.231:8081"
},
"Tunnel": {
"Port": "8080"
}
},
"ManagementUI": {
"ListenAddress": "192.168.5.231:4433",
"Enabled": true
},
"Authenticators": {
"Issuer": "fx_wg_wag",
"DefaultMethod": "totp",
"Methods": [
"totp"
]
},
"Wireguard": {
"DevName": "wgpa01",
"ListenPort": 51820,
"PrivateKey": "Private_key_removed",
"Address": "10.125.0.1/16",
"MTU": 1420,
"PersistentKeepAlive": 25,
"DNS": [
"192.168.5.1/32"
]
},
"Acls": {
"Groups": {
"group:users": [
"user02",
"user03",
"user04",
"user05"
],
"group:administrators": [
"user01",
"user10"
]
},
"Policies": {
"*": {
"Allow": [
"10.125.0.1/32 8080/any"
]
},
"group:users": {
"Allow": [
"10.125.0.1/32 8080/any"
],
"Mfa": [
"10.125.0.0/16",
"192.168.5.0/24",
"192.168.6.0/24"
]
},
"group:administrators": {
"Allow": [
"10.125.0.0/16",
"192.168.5.0/24",
"192.168.6.0/24"
]
}
}
}
} |
|
Sweet thanks. Please give me what you're trying to hit in the VPN network as well (i.e |
ping 10.125.0.1 (the wag server ip) |
Reverted to 6.0.1 and it worked. We were able to go to 10.125.0.1:8080 to enter the MFA code and then we were able to ping and ssh 10.125.0.1. But the config we use for 6.0.1 is different. No policy for groups (maybe that's the problem?). "Policies": {
"*": {
"Mfa": [
"10.125.0.0/16",
"192.168.5.0/24",
"192.168.6.0/24"
],
"Allow": [
"10.125.0.100/32"
]
}
}
} |
|
Yeah cool I see what the issue is now. You have defined this The reason 6.0.1 worked is because it was forcing you not to have duplicate rules, so the default If you change your rule to be |
Still not working. "Policies": {
"*": {
"Allow": [
"10.125.0.1/32 8080/any icmp"
]
},
"group:users": {
"Allow": [
"10.125.0.1/32 8080/any icmp"
],
"Mfa": [
"10.125.0.0/16",
"192.168.5.0/24",
"192.168.6.0/24"
]
},
"group:administrators": {
"Allow": [
"10.125.0.0/16",
"192.168.5.0/24",
"192.168.6.0/24"
]
}
} |
|
Sweet, give me the output of |
Changed from 10.125.0.1/32 to 10.125.01 |
|
Sorry, when I mean changing it to 10.125.0.1 I mean remove all other restrictions and just leave it as "10.125.0.1" Regardless, I can replicate. Effectively when the icmp directive is at the end like this Obviously, that little bit is a bug. Ironically not what you're getting hit by, but still a bug |
Works now! Thank you very much. |
|
Honestly. Thank you. You've just helped me find a really corner case bug!! Im going to do a little release in a second in order to make the |
Tested working. Tested the config below but still cannot SSH 10.125.0.1. |
|
Ahhh I totally get what you're saying here. You want users to be able to hit some ports on a host without Mfa and some other set of ports when they have mfa'd That's a good point and not something I've designed wag to do. I'd have to have a think about it and whether it's feasible. To cover all my bases, you can always add 22/tcp to your server rule to enable ssh. But obvious this would allow clients to hit ssh even when they hadn't authorised with Mfa. Good shout! As for the rest of the 10.125.0.0/16 network, it should be able to hit all services when mfa'd there. |
|
Thank you so much NHAS! As you correctly pointed out, this is really an edge case. But it is good to have it because it is how Openvpn works (peers can access each other via VPN tunnel IP). We are currently using Openvpn with MFA on PFSense firewall. |
|
I definitely agree that the option to do this should be here. I just want to have it be secure by default. i.e you have to configure it specifically to allow clients to hit each others services This just stops easy lateral spread in the event a single device gets compromised. As for the allowed ports changing on Mfa I think that's a great idea but may not be feasible with the implementation as it is Regardless I fixed a bug from this discussion so thanks for your contribution! |
Actually as I don't have any other client, I don't know if the MFA 10.125.0.0/16 works. If it works for all devices in 10.125.0.0/16 except 10.125.0.1/32 (because the more specific Allow rule takes precedence), then the current 6.1.2 version may be good enough. After all, the purpose is to be able to access the other peers and not the server. Will try to set up another client and then test it out. Thank you. |
|
Sweet, I've added what you wanted port wise. https://github.com/NHAS/wag/releases/tag/v6.2.0-pre-release See the release notes here (more docs on the unstable branch) This will mean that for the server address specifically that you cant remove the Effectively this means you can have MFA and Allow rules for the same route, and do fun stuff like: "*": {
"Mfa": [
"10.0.0.0/16",
"10.0.1.1/32 22/tcp",
]
},
"group:users": {
"Allow": [
"10.0.1.1/32 443/tcp",
]
}Where a user in the If you want to be helpful I'd love for you to give this a really hard test and just try and abuse it as much as possible. Then I'll probably do a release. |
|
Thank you NHAS. I'm travelling now and won't be able to test this until maybe next month. |
|
Dang alright! Safe and happy travels |
|
Hi NHAS Tested 6.2.0 and it works! Was able to ssh to the WG server at its VPN IP address after entering MFA code. Thank you so much! An aside: I'm in a place where the Internet is severely censored and surveilled. Fearing that they may block 51820, I tried running Wireguard under port 443 (instead of 51820) but it didn't work. Checked that port 443 wasn't used on the WG server. Is there any reason why port 443 won't work for Wireguard? "Wireguard": {
"DevName": "wireguard1",
"ListenPort": 443,Below is my config.json (tested a user in the users group) : "Policies": {
"*": {
"Allow": [
"10.125.0.1/32 8080/any icmp"
]
},
"group:users": {
"Mfa": [
"10.125.0.1/32 22/tcp",
"10.125.0.0/16",
"192.168.5.0/24",
"192.168.6.0/24"
]
},
"group:administrators": {
"Allow": [
"10.125.0.0/16",
"192.168.5.0/24",
"192.168.6.0/24"
]
} |
|
Glad to hear that all works for you. Please test it a bunch and then I'll do a release. In terms of this: "I'm in a place where the Internet is severely censored and surveilled" Its probably best to warn you that wireguard as a protocol is very easy to pick up with packet inspection due to some very identifiable message characteristics (as example net4people/bbs#88). So I would not recommend using wireguard alone if you are in a hostile nation, or other dangerous situation. As for the issue you've described. There is no immediate reason that wireguard shouldnt be able to listen on port 443, can you give me more information? What port is your webserver listening on? |
|
It is okay. I think 443 not working because of the network here. I need to go to another place to test. Thank you. What port is your webserver listening on? 8081 Are there any wag logs I can look at? /var/log/syslog (see below) "Webserver": {
"Public": {
"ListenAddress": "192.168.5.231:8081"
},
"Tunnel": {
"Port": "8080"
}
},
"ManagementUI": {
"ListenAddress": "192.168.5.231:4433",
"Enabled": true
}, |
|
Yeah all that looks fine, so I dont think its an issue with wag or the host. I think you'll find its a network issue. If you're living with a hostile network, it may be that the deep packet inspection is closely monitoring 443/udp, so when it sees traffic that isnt QUIC (https's encrypted udp transport) then it just drops those packets. However I would have expected it to kill any traffic it saw that was on odd udp ports and clearly wireguard. But this is just a guess from my perspective. |
Hi All
In OpenVPN, our clients are able to access each other using the VPN tunnel IP address. We are unable to do this with WAG.
10.125.0.0/16is the VPN tunnel network.10.125.0.1is the VPN tunnel IP address of the WG interface of our WG "server".The config below does not work because the Mfa takes precedence over the Allow. So 10.125.0.1 also requires MFA and therefore we cannot reach http://10.125.0.1:8080 to enter the MFA code.
To make it work, we have to remove the
"10.125.0.0/16"from the Mfa. The config below works:But we want to be able to reach all the other peers in the VPN tunnel network 10.125.0.0/16 like we can do with OpenVPN. We tried doing
"Mfa": [ "10.125.0.0/16 1-8079/any 8081-10000/any"]but it didn't work."Mfa": ["10.125.0.1 1-8079/any 8081-10000/any"]also did not work.Looks like there's no way to do this?
Except specifying all the peers IP addresses in
10.125.0.0/16one by one except10.125.0.1(since"10.125.0.1 1-8079/any 8081-10000/any"does not work) ?Thank you very much in anticipation.
The text was updated successfully, but these errors were encountered: