I think there is a bug with static ports. I always had dynamic ports disabled and fixed to

51831

, but after update to

0.14.5

wireguard started on port

51832

which is not whitelisted and thus the node was not accessible from outside. If

netclient

couldn't bind to the port it should fail instead of using a different one

I think there is a bug with static ports

Unable to enable UDP hole punching

Hey Team, Quick question. I am upgrading from 0.9.1 to the latest version. The upgrade documents say that it is possible with simple modifications to the docker-compose file...

However when I do the upgrade, all the settings, clients and configurations are lost... Is that to be expected?

pretty much- there's been so many changes to the software that it's better to start again. In particular- even if you do get it to work, you may have database issues. Easiest way might be to set up a new VM as a server and manually copy settings. But you can see from my message right above yours that even doing it this way can have issues...

@future-ram-24559 Do you think it is stable now, looking at using it for production?

@victorious-toddler-87108 - I'm mostly Mac based and very excited about the new package installer. I don't know much about other osen, but my understanding is that their goal was to have it mostly or wholly feature complete about now. Likely we are in the last few releases before v1.0 From my POV, I have complete control over all the Macs I manage, so I could roll out a bugfix pretty quickly if something went wrong. I've installed the server a number of times so I could fix that if smoke started coming out. So I can't say 100% ready- but I am planning to use in prod as soon as I can finish testing. Obviously a test rollout to start, but the team has done amazing things since the early days, and this is the best Wireguard overlay project I've found, and I hope I can make VPN the 'backup' connectivity solution in favour of Netmaker real soon.

@future-ram-24559 Thanks homie...I made the mistake of using the DO marketplace

Got it all up and running and threw a device outthere, trying to see if I cam reverse ssh into the device and bring down the tunnel and bring it backup with a new config...

ah I see, yeah physical or network access could be important there!

upgrading from 0.9

Hi all, I setup netmaker using "Quick install" and "Getting Started" guides on the docs website. I've setup a netclient node as well as an external wireguard client. In the network details, I also setup a default external client dns server as the vpn ip address of the netclient node that I setup. For some reason, when querying the DNS server through it's IP address, it seems that the CoreDNS server replies. I can even see that in my Wireguard client, the DNS IP address is set correctly, but the DNS queries do not make it to my custom DNS server, and instead show up in the CoreDNS logs anyways. Is there a reason that CoreDNS would be receiving the DNS queries instead of my own server?

All clients lose connectivity when UDP hole punching enabled

Netmaker cluster nodes status

Node has no Connectivity

. Hi all, I’m having trouble reaching services advertised on k3s from external clients… My setup is: - Netmaker 0.14.5 via docker-compose, and netclients installed using apt. - WireGuard subnet 10.70.0.0/20 - K3s/flannel installed on top of WireGuard mesh with 2 regions: - Region 1: master A, workers C,D,E - Region 2: master B, workers F,G,H - Netmaker Ingress nodes are A, B, C My issue is: - I advertise a Loadbalancer service on worker C. Metallb(L2) gives it IP 10.70.15.1 - From nodes A-H, service S is reachable. - From my external clients vpn’d to ingress A, B the service is not reachable. - From external clients vpn’d to ingress C, the service is reachable. Could someone point me in the right direction on where to look?

i wonder whether anyone has metallb with netmaker/wireguard working - it seems i'm must be missing a route somewhere, but i'm not sure whose responsibility it is to create that route.

ah hold on - i might be onto something. I found an archived conversation in #933522294872088636 between @jolly-london-20127 and @hallowed-mechanic-22995 describing my exact problem

I'm not 100% certain but as far as I can remember, your ingresses need to be worker nodes as well to make this happen. Here's my conclusion from back then: https://discord.com/channels/825071750290210916/920313856604110898/974334369344942091 I wasn't able to write a tutorial, but will do asaic

I understand in your case A and B are only master nodes

this is some metallb stuff i don't fully understand but it worked when making my ingress node a worker node as well.

yes, I havent quite understood it yet either, but I'm definitely missing some routes somewhere.

...thanks for the pointer to your conclusion. I only partially match your result. It seems I need to VPN to the node running the service with the external-ip itself. If i VPN via the netmaker ingress to a different k3s worker, the service is not curlable or pingable from my external client.

i will try alex's suggestion of allocating a metallb range outside of the netmaker subnet and creating an egress

ok... i think i have a solution using @jolly-london-20127 's suggestion, ...but its not pretty

my metallb range is 10.71.0.0/24 (wireguard is 10.70.0.0/20)

i had to make every node in my k3s install an egress to (10.71.0.0/24, nm-k3s)

which was time-consuming as i had to do it manually per-node via the UI

going to test some more ideas later on, but i'm currently just trying to figure out whats really going on

making the wireguard node an egress, allows forwarding from any node (10.70.0.0/20) to the metallb ip range (10.71.0.0/24). but, for some reason, once the packet reaches the egress node, it doesnt seem to make the final hop to the k3s-node where the kubernetes service is actually running.