Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: Improve documentation around Network Access Controls #8

Open
bbigras opened this issue Aug 8, 2023 · 4 comments
Open

docs: Improve documentation around Network Access Controls #8

bbigras opened this issue Aug 8, 2023 · 4 comments
Labels
documentation Improvements or additions to documentation

Comments

@bbigras
Copy link
Contributor

bbigras commented Aug 8, 2023

the default behavior only lets people peer up if there is a Network ACL allowing it. Those are managed via the admin API, but you can set a default allow-all rule at bootstrap with --bootstrap.default-network-policy=accept.

Originally posted by @tinyzimmer in #5 (comment)

Which ACLs do I need for peering? Is it like 8443, 9443?

@tinyzimmer
Copy link
Contributor

tinyzimmer commented Aug 9, 2023

Nah. This is getting in to the stuff that has near zero documentation and very little testing. Once the networking fundamentals are stabilized I really need to give the whole RBAC system some love.

The cidr/port filters are not fully fleshed out - you should be able to get by with the node filters. So, for example, to allow a node node-2 to peer to node-1:

wmctl put networkacl acl-name --src-node node-1 --dst-node node-2 --accept

And (if my memory serves) you'll need a reverse of the rule as well. You can also collect nodes into groups and create ACLs using the group:<group-name> format for the node arguments.

@tinyzimmer
Copy link
Contributor

Since you are actively playing with this functionality - I'd love to incorporate any feedback you might have. So feel free to call out any areas where you think things might work better.

@tinyzimmer tinyzimmer changed the title which ACLs are needed for peering? docs: Improve documentation around Network Access Controls Aug 10, 2023
@tinyzimmer tinyzimmer added the documentation Improvements or additions to documentation label Aug 10, 2023
@bbigras
Copy link
Contributor Author

bbigras commented Aug 11, 2023

It's weird, I'm not using --bootstrap.default-network-policy=accept, but ping and ssh works between the 2 nodes.

Could it be caused by --global.verify-chain-only? I'm guessing this is only for mtls.

# server
sudo webmesh-node \
     --global.detect-endpoints \
     --global.mtls \
     --global.tls-cert-file=/opt/webmesh/tls.crt \
     --global.tls-key-file=/opt/webmesh/tls.key \
     --global.tls-ca-file=/opt/webmesh/ca.crt \
     --wireguard.key-file=/opt/webmesh/wg-key \
     --bootstrap.enabled \
     --wireguard.listen-port 51821 \
     --global.primary-endpoint vps_real_ip \
     --global.no-ipv6 \
     --plugins.ipam.static-ipv4=server=172.16.0.1/32 \
     --plugins.ipam.static-ipv4=rpi=172.16.0.2/32

# rpi
sudo webmesh-node \
     --global.detect-endpoints \
     --global.mtls \
     --global.tls-cert-file=/opt/webmesh/tls.crt \
     --global.tls-key-file=/opt/webmesh/tls.key \
     --global.tls-ca-file=/opt/webmesh/ca.crt \
     --wireguard.key-file=/opt/webmesh/wg-key \
     --global.verify-chain-only \
     --mesh.join-address=vps_real_ip:8443 \
     --wireguard.listen-port 51821 \
     --global.no-ipv6

@tinyzimmer
Copy link
Contributor

tinyzimmer commented Aug 11, 2023

This is just a lot of uncharted territory. CIDR/Port filtering is not yet implemented. The reason being the implementation will have to be specific for each platform and will take time (and hopefully more developers). The node itself is not inspecting traffic - it is only setting up the interfaces. So to do IP/Port filtering - nodes need to evaluate the ACLs locally and apply to their firewalls what they should allow/block.

That being said - what should be working right now is that if there is no rule that at least allows two nodes by their IDs to communicate with one another - the connection should not be established. Beyond that - once the connection is established, all traffic between the peers should be allowed. If that is not working as intended, it's definitely the first thing that needs to be addressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

2 participants