One week later....

[B08Z]

First and foremost I want to thank you for this amazing work. I have been using for a week or so and have settled on it above, Tailscale/Headscale, Netbird, Pangolin, Netmaker.

Its simple and effective - and FOSS!

I wanted to give you some ideas. I think they would make a great addition but also appreciate that they may be too niche to be worth implementing. I would be happy to test any of them and support with documentation if it would help.

In no particular order:

1. Enable the enrolment of Crowdsec Security engine.

This can currently be achieved by executing the following command in the Crowdsec container:
cscli console enroll -e context XXXXXX-KEY-XXXXX
The key is obtained when you login to your Crowdsec account and select enroll.

This would enable users to contribute to the crowdsec community as well as see all their other security engines in one place.
Ideally this would be enabled via the inclusion of an environment variable
CROWDSEC_ENROLL_KEY

2. Allow Gateways for multiple subnets.

There are several reasons why this might be useful, such as the deployment of a gateway node onto a router with multiple LAN/VLANs. It would reduce the number of clients/gateways needed.
I have already been successful in manually setting this up by editing the WG.conf to add the following for example:
PostUp = iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o eth1 -j MASQUERADE
PostUp = iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o eth2 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.10.10.0/24 -o eth1 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.10.10.0/24 -o eth2 -j MASQUERADE

And then adding the route on the Wiredoor container.

eth1 and eth2 being the ethernet adaptors for each subnet - Allowed IPs set on peers.
This works perfectly but adding a client / changing routes can override the settings.

It would be amazing to see the option to add additional subnets in the frontend.

3. Have an option to manually set the eth adaptors name.

Curretly all WG.conf are set up with eth0 as the default for any POSTROUTING / MASQUERADE. Having the ability to manually set this during config or setting an auto detect would be great. Having both is needed in case a user wants to deploy by downloading the WG config file.

4. Ability to set the DNS in the WG config

A simple check box to enable the config to be updated with a custom DNS. - This would just be another line to the WG.conf.

I think 2, 3 and 4 could be hidden behind an advance settings toggle in the front end, so as not to over complicate things (for the user).

4. Multiple exit nodes.

I dont know how feasible this would be, but having and ability to set up exit nodes and then selecting which clients would be routed out of which exit node.

The idea is that for clients that have all their internet traffic routed in the WG tunnel can be made to use a specific exit node via the interface.

5. Authentication exceptions - API endpoints

The idea is to enforce authentication (via OAuth2-proxy) for dashboards or sensitive URLs but allow API endpoints to be exposed without the need for authentication.

6. Load balancing of routes.

Where you have 2 or more gateways advertising the same route allow the user to select the prioritisation for each gateway and have fail over or load balancing to select the most appropriate route.

I know there is a lot here, I am more that happy to provide detail on each separately if you or others think its a good idea. Equally I am really happy with Wiredoor so if nothing changes I am really not going to complain.

[dmesad]

Hi @B08Z,

Thank you so much for your detailed message and kind words.

At the moment, I’m not able to fully review each of your suggestions, but I’ve read through them and I’ll definitely get back to you on each point as soon as I can. There are some great ideas here and I’m excited to dig into them properly.

In the meantime, feel free to reach out anytime at [email protected], that’s the best way to stay in touch with us directly.

Thanks again for being part of the Wiredoor community!

[dmesad]

Hi @B08Z,

I've now had the chance to review each point in detail, and I wanted to follow up with a breakdown of where we stand and how we plan to move forward.

CrowdSec enrollment

This is already supported directly by the official CrowdSec image using the ENROLL_KEY environment variable:

https://hub.docker.com/r/crowdsecurity/crowdsec#reference

We’ll be adding a note in the documentation to guide users who want to enroll their instance in the CrowdSec Console.

Multiple subnets per gateway node

This is a great idea and very much aligned with our roadmap. We’re planning to introduce an Node Advanced Mode, where users will be able to define multiple interface + subnet pairs per node.

Issue #89

Manual interface selection

This is fully covered by the upcoming Node Advanced Mode as well. When defining multiple subnets, each one will be explicitly tied to an interface, allowing you to move beyond the default eth0.

Custom DNS in WireGuard config

We agree this would be useful in certain scenarios. However, overriding the DNS can break Docker and Kubernetes gateways, which rely on internal DNS (like 127.0.0.11 or CoreDNS) to resolve internal service names.

We will support this option under Advanced Settings, with proper warnings for gateway nodes.

Issue #88

Exit nodes

This is currently not compatible with Wiredoor’s architecture, since we require that gateway nodes do not overlap with the VPN subnet. Routing full internet traffic (0.0.0.0/0) through an exit node would break this model.

Authentication exceptions for specific paths (oauth2-proxy)

Great suggestion! we had already considered this and your feedback reinforces its priority.

issue #90

Load balancing of routes.

Currently, Wiredoor only allows one gateway to advertise a given subnet. Supporting multiple gateways per subnet would require a significant routing layer redesign, and WireGuard itself does not natively support failover or load balancing.

---

Thank you so much for your insights and the time you put into this. Feature requests like these push Wiredoor forward, and we truly appreciate your help in shaping it.

[dmesad]

Hi @B08Z,

Regarding point 5 (Authentication exceptions – API endpoints), that feature is now implemented 🎉

You can now enforce OAuth2 authentication for dashboards or sensitive routes while allowing specific API endpoints to remain public.

Check out the documentation and feel free to try it out:

👉 https://www.wiredoor.net/docs/usage#bypass-authentication-for-specific-paths

Would love to hear your feedback once you test it!

[B08Z]

Working exactly as I would have expected - awesome.

Something that you could consider, not at all critical, is having the ability to reverse the bypass config.
Much like Allow IP or Deny IP you could have by-passed URLs (as is now) or allow the user to set authenticated URLs (all else would be by-passed).

The only reason I suggest this is it might make it easier for some if they know they want to enable oAuth to say https:service.home.lan/login/ but they dont know what the api or other endpoints are.

For me the current implementation is perfect and an implementation as I have suggested above could lead to ambiguity resulting in unauthenticated services with out the users knowledge.

[B08Z]

Hi @B08Z,

Regarding point 5 (Authentication exceptions – API endpoints), that feature is now implemented 🎉

You can now enforce OAuth2 authentication for dashboards or sensitive routes while allowing specific API endpoints to remain public.

Check out the documentation and feel free to try it out:

👉 https://www.wiredoor.net/docs/usage#bypass-authentication-for-specific-paths

Would love to hear your feedback once you test it!

Hi @dmesad Just had a thought, would it be possible to bypass Oauth based on http methods:

GET
POST
PUT
...

location /service/public {

   limit_except GET {
        deny all;
    }
    proxy_pass http://service:8020;
    include partials/proxy.conf;
}

[dmesad]

2. Allow Gateways for multiple subnets.

There are several reasons why this might be useful, such as the deployment of a gateway node onto a router with multiple LAN/VLANs. It would reduce the number of clients/gateways needed. I have already been successful in manually setting this up by editing the WG.conf to add the following for example: PostUp = iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o eth1 -j MASQUERADE PostUp = iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o eth2 -j MASQUERADE PostDown = iptables -t nat -D POSTROUTING -s 10.10.10.0/24 -o eth1 -j MASQUERADE PostDown = iptables -t nat -D POSTROUTING -s 10.10.10.0/24 -o eth2 -j MASQUERADE

And then adding the route on the Wiredoor container.

eth1 and eth2 being the ethernet adaptors for each subnet - Allowed IPs set on peers. This works perfectly but adding a client / changing routes can override the settings.

It would be amazing to see the option to add additional subnets in the frontend.

Hi @B08Z,

You can now define multiple subnets and interfaces per gateway node directly from the frontend.

You can also set a custom DNS, which will be added to the WireGuard config.

Both options are available under Advanced Settings when editing or creating a node.

Please give it a try and let me know if everything works as expected. We'll finalize the release with your feedback!

[B08Z]

Great, I'll give it a go tomorrow and let you know how I get on.

[B08Z]

@dmesad
Pulled the new image and the advanced tab works great. I have managed to add a gateway with 3 different nets a mixture of VLAN normal LAN and Docker net all working.

• I will create an issue / bug report but the latest build breaks Oauth2Proxy. I have not changed anything on the config but any service with requiresAuth fails to work.
  The TLD domains that use it cant be saved if its removed - form just hangs

• The default wiredoor service also seems to need to be configured with wiredoor as the host not 127.0.0.1 - again bug report to follow.