Issues with acls/policies and ssh session connections (mtu)

[nhas]

Issues with acls/policies and ssh session connections (mtu)

[paulb-opusvl]

I don't know if this will help, but here's an article I wrote, with config in it.

https://warlord0blog.wordpress.com/2022/09/29/wireguard-otp-and-acls/

For each of the Mfa and Allow entries, you must match them on the client side with the AllowedIPs in their client config. eg.

[Interface]
PrivateKey = SuperSecretKey
DNS = 10.0.6.254
Address = 192.168.254.19

[Peer]
Endpoint =  X.X.X.X:51820
PublicKey = SecretKey
AllowedIPs = 10.0.6.0/24, 192.168.254.1/32, 10.0.4.0/24
PersistentKeepAlive = 10

If I wanted to include a single host, 10.7.7.7 as per your posted example, I must also have that in the AllowedIPs

AllowedIPs = 10.0.6.0/24, 192.168.254.1/32, 10.0.4.0/24, 10.7.7.7/32

[NHAS]

Hi there @111blackeagle111,

A short answer to your issue title is, Yes it does work.

The long answer to your question is, this acts as a firewall on-top of the wireguard device. When you, or your users authenticate it simply allows whatever ip/subnet to pass through the host.

Wag tries not to touch the host configuration as much as possible, so it does not set the ip_forward sysctl flag automatically, which might be causing you to not be able to route from your wag server to other networks.

Unfortunately I dont think drawing a diagram is going to help much here, as it would just consist of showing a wag server connected to the hosts that you define in the Polices list, as it wont be able to route traffic to things its not connected to.

Could you please describe the problem you're having in a bit more depth?

(also thanks @paulb-opusvl 😄 )

[NHAS]

(Just as a side note to that comment, if you use the wag registration endpoint it'll do all the allowedips for you)

[NHAS]

Glad to hear it, sometimes networks can be a bit odd if the MTU of your network isnt optimal for ethernet header + wireguard header, generally this is fine with 1420 on most ethernet based networks as this accounts for the wireguard header size.

Next time you create an issue, could you please title it with the issues you're having, and some information about your problem. It helps me with helping you debug it.

Asking the inflammatory question of "but does it work" is less likely to foster a helpful attitude.

@111blackeagle111

[paulb-opusvl]

We use it such that "some" external/public addresses are routed from our WireGuard. This is due to IP filters some of the externals have. We have to come from our Office IP.

The important part is the routing/gateway on the WireGuard server. From there you must be able to route to your destinations, public or otherwise. Then we ensure that the AllowedIPs on the clients includes those public addresses, then the client knows to route to the WireGuard server.

Image: https://imgur.com/iD45u1O

[111blackeagle111]

Thanks for the quick reply. Could you give me a drawing of the example configuration you put on the project page?
So I can reason from your example configuration. Thank you very much

{
    "Lockout": 5,
    "HelpMail": "[email protected]",
    "MaxSessionLifetimeMinutes": 2,
    "SessionInactivityTimeoutMinutes": 1,
    "ExternalAddress": "192.168.121.61",
    "DatabaseLocation": "devices.db",
    "Issuer": "192.168.121.61",
    "DNS": ["1.1.1.1"],
    "Webserver": {
        "Public": {
            "ListenAddress": "192.168.121.61:8080"
        },
        "Tunnel": {
            "ListenAddress": "192.168.1.1:8080"
        }
    },
    "Wireguard": {
        "DevName": "wg0",
        "ListenPort": 53230,
        "PrivateKey": "AN EXAMPLE KEY",
        "Address": "192.168.1.1/24",
        "MTU": 1420,
        "PersistentKeepAlive": 25
    },
    "Acls": {
        "Groups": {
            "group:nerds": [
                "toaster",
                "tester",
                "abc"
            ],
        },
        "Policies": {
            "*": {
                "Allow": [
                    "10.7.7.7",
                    "google.com"
                ]
            },
            "username": {
                  "Allow":[ "10.0.0.1/32"]
            },
            "group:nerds": {
                "Mfa": [
                    "192.168.3.4/32"
                ],
                "Allow": [
                    "192.168.3.5/32"
                ]
            }
        }
    }
}

[111blackeagle111]

I managed to make all the configurations go the right way.
After I had problems with ssh connections but I solved by setting the MTU = 1200 parameter inside the wireguard configuration file of the client and now ssh connections also work, after doing two-factor authentication.