MFA port accessible without authentication

[softScheck]

Hey there,

there is an issue we have come up with. The setup is the following: wag runs on a system with the IP 192.168.1.2 and has the IP 10.1.2.1 for its WireGuard interface. The Tunnel listener is set to Port 443 for the authentication web UI and the 192.168.1.0/24 network is set as MFA only for everyone.

The problem is, after the initial WireGuard connection and without authentication Port 443 is accessible on 192.168.1.2 as well but shouldn't without authentication. When the authentication is done, 192.168.1.2 should be accessible with all ports but has still only port 443 reachable.

Hope you can help us there. Thanks a lot :)

[NHAS]

Hi there!

That is an odd bug, can you please provide the output of ./wag firewall -list or if you're using the web UI Diagnostics -> Firewall state

And perhaps also the output of ss -lt

[softScheck]

I have narrowed down the problem. The behavior is connected with setting the DNS to IP 192.168.1.2 - that created a public route according to the firewall list. The expected behavior for me would have been the DNS entry of the resulting WireGuard configuration and not a complete public host. Or at least only port 53 open on that system. An easy solution to this behavior was to set the DNS IP to 10.1.2.1 and use the Exposed Host entry to forward port 53 TCP and UDP. It's still somewhat odd because MFA policies should always precede public ones, right?

What still troubles me is, that after authentication on 10.1.2.1 for 192.168.1.2, nonetheless only the same ports that haven been open before authentication are accessible. So in this case port 433, other ports that are opened on this system, like ssh (port 22) are not accessible through WireGuard.

{"fha":{"Policies":["10.1.2.1/32 policy [public(20) any/any]","192.168.1.2/32 policy [public(20) any/any]","192.168.1.0/24 policy [mfa(16) any/any]"],"Devices":[{"LastPacketTimestamp":0,"Expiry":0,"IP":"10.1.2.5","Authorized":false}],"AccountLocked":0},"jto":{"Policies":["10.1.2.1/32 policy [public(20) any/any]","192.168.1.2/32 policy [public(20) any/any]","192.168.1.0/24 policy [mfa(16) any/any]"],"Devices":[{"LastPacketTimestamp":0,"Expiry":0,"IP":"10.1.2.6","Authorized":false}],"AccountLocked":0},"sku":{"Policies":["10.1.2.1/32 policy [public(20) any/any]","192.168.1.2/32 policy [public(20) any/any]","192.168.1.0/24 policy [mfa(16) any/any]"],"Devices":[{"LastPacketTimestamp":0,"Expiry":0,"IP":"10.1.2.4","Authorized":false}],"AccountLocked":0},"wki":{"Policies":["10.1.2.1/32 policy [public(20) any/any]","192.168.1.2/32 policy [public(20) any/any]","192.168.1.0/24 policy [mfa(16) any/any]"],"Devices":[{"LastPacketTimestamp":0,"Expiry":0,"IP":"10.1.2.3","Authorized":false}],"AccountLocked":0}}

[JSmith-Aura]

Ah yes, that makes sense. DNS gets an entry added for it so that you can resolve your internal services. So for example, if you have TLS and want to go to vpn.internal but are capturing DNS via your wireguard tunnel enter into a state where you cant resolve anything, thus cant MFA.

The reason you cant access anything on the 192.168.1.2 address is because Wag uses iptables to restrict what can be accessed, so you dont accidentally expose sensitive things to the tunnel before you MFA.

If you check iptables -L -n you'll see the wag entries in the filter table, and also see how the default policy for INPUT is drop.

Unfortunately the only way to really get around this is to manually add your own iptables rule for your specific iptable/port combination on the host.

[JSmith-Aura]

The expected behavior for me would have been the DNS entry of the resulting WireGuard configuration and not a complete public host

This happens because of a (relatively) recent change that adds the concept of port restrictions to wag. I agree that now that we have the ability to specify ports in wag that this should be limited to 53/tcp/udp rather than an any/any good catch!

It's still somewhat odd because MFA policies should always precede public ones, right?

Unfortunately this changed back in 7.0.0 in response to #43.

Effectively in that users case they had created this configuration:

 "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"
                ]
            },

But effectively could not access their 10.125.0.1 because of the MFA precedence of 10.125.0.0/16. Which is kind of limiting in my personal opinion, so I updated it to be the most specific route.

[softScheck]

Thanks for making that clear! With the DNS on 10.1.2.1 the 192.168.1.2 IP is now private until I authenticate. What still bugs me is, that after authentication I'm still only able to access the same ports that have been open on IP 10.1.2.1 This feels like there are some rules that should be active on an interface basis (only the WireGuard one) but are active global on all interfaces...

[JSmith-Aura]

The reason you cant access anything on the 192.168.1.2 address is because Wag uses iptables to restrict what can be accessed, so you dont accidentally expose sensitive things to the tunnel before you MFA.

If you check iptables -L -n you'll see the wag entries in the filter table, and also see how the default policy for INPUT is drop.

[JSmith-Aura]

The reason for this, is that the wag needs to be very very certain that it is not exposing the Tunnel port, or any other services either to the tunnel or externally without a great deal of effort.

The worst possible outcome would be someone accidentally exposing the management web UI, or the tunnel listener port to some area that can spoof IP addresses.

[NHAS]

I've pushed a patch to unstable which changes the DNS server firewall rules to 53/any rather than any/any Feel free to check it out.

I am going to close this issue now as the other items you've brought up are more or less by design, as infuriating as that design might be :P

[softScheck]

Perfect, thanks for the explanations - I know how to deal with this now, and you also changed the DNS setting :+1: