seems failing with userland

so in the netmaker helm charts where is the wireguard-go pod for userland?

I just installed netmaker in my k8s cluster using the helm-chart. Values are as follows: baseDomain: netmaker. replicas: 3 ingress: enabled: true className: traefik tls: issuerName: letsencrypt-prod RWXStorageClassName: standard dns: enabled: false postgresql-ha: postgresql: replicaCount: 2 persistence: enabled: true size: 10Gi storageClass: standard ui: replicas: 2 mq: replicas: 2 singlenode: false storageSize: 1Gi wireguard: enabled: true kernel: true it now created a NodePort Service probably for the wireguard ports. How do I know, which ports I have to forward in my firewall to which host. The cluster consists currently of 3 worker nodes with hardware wireguard installed. And how does the netmaker client/netclient later knows where to connect to? As netmaker probably doesn't know about the external/wan ip address.

Network Architecture Learning Curve - What controls what?

as @incalculable-musician-80046 has mentioned above there seems to be some issues with the userland implementation of netclient 'gravitl/netclient:v0.17.0' running in k8s

getting logs like: `[netclient] 2022-12-20 12:43:27 error running command: wg-quick up /etc/netclient/config/nm-dev.conf [netclient] 2022-12-20 12:43:27 [#] ip link add nm-dev type wireguard Error: Unknown device type. Unable to access interface: Protocol not supported [#] ip link delete dev nm-dev Cannot find device "nm-dev" [netclient] 2022-12-20 12:43:28 error running command: wg-quick up /etc/netclient/config/nm-dev.conf [netclient] 2022-12-20 12:43:28 [#] ip link add nm-dev type wireguard Error: Unknown device type. Unable to access interface: Protocol not supported [#] ip link delete dev nm-dev Cannot find device "nm-dev" file does not exist [netclient] 2022-12-20 12:43:29 error installing: could not reliably create interface, please check wg installation and retry [netclient] 2022-12-20 12:43:29 error running command: wg-quick down /etc/netclient/config/nm-dev.conf [netclient] 2022-12-20 12:43:29 wg-quick:

nm-dev' is not a WireGuard interface
[netclient] 2022-12-20 12:43:29 removed systemd remnants if any existed
[netclient] Starting netclient daemon
[netclient] 2022-12-20 12:43:29 [daemon.go-42] Daemon(): netclient daemon started -- version: v0.17.0
[netclient] 2022-12-20 12:43:29 [mqpublish.go-30] Checkin(): starting checkin goroutine
[netclient] 2022-12-20 12:44:29 [mqpublish.go-43] Checkin(): MQ client is not connected, skipping checkin...
[netclient] 2022-12-20 12:45:29 [mqpublish.go-43] Checkin(): MQ client is not connected, skipping checkin...

implementation is: --- apiVersion: apps/v1 kind: Deployment metadata: name: netclient namespace: callum-netmaker-agent labels: app: netclient spec: selector: matchLabels: app: netclient replicas: 1 template: metadata: labels: app: netclient spec: hostNetwork: true containers: - name: netclient image: gravitl/netclient:v0.17.0 env: - name: TOKEN value: "REDACTED" volumeMounts: - mountPath: /etc/netclient name: etc-netclient securityContext: privileged: true volumes: - hostPath: path: /etc/netclient type: DirectoryOrCreate name: etc-netclient serviceAccount: netclient --- apiVersion: v1 kind: ServiceAccount metadata: name: netclient namespace: callum-netmaker-agent labels: app: netclient --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: system:netclient:scc:privileged rules: - apiGroups: - security.openshift.io resourceNames: - privileged resources: - securitycontextconstraints verbs: - use --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: system:netclient:scc:privileged roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:netclient:scc:privileged subjects: - kind: ServiceAccount name: netclient namespace: callum-netmaker-agent

@breezy-dentist-99929 the gravitl/netclient:v0.17.0 image expects WireGuard to be installed on the hosts. This is the preferred way, but to use userspace (embedded) WireGuard, you can use the gravitl/netclient-go:v0.17.0 image

awesome this is what i was missing: gravitl/netclient-go:v0.17.0

Whenever I try to start k3s with any of the node-ip / node-external-ip / flannel-iface options it just hangs forever with no logs, any clue about this?

clients are all connected and pingable

this is the command I used

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC=”server --node-ip 10.143.115.2 --node-external-ip 10.143.115.2 --flannel-iface nm-fmt-k3s” sh -

network range is 10.143.115.0/24

hmm it seems like its trying to access 127.0.0.1:6443 which doesnt work since its on a different interface

I've finally gotten it to work, but now i got a second problem, how can I get nginx ingress-controller to poke through?

the helm charts here seem to have fallen quite badly out of date: https://github.com/gravitl/netmaker-helm/ is it enough to just update the NM image versions to 0.17.1 ?

GitHub - gravitlnetmaker-helm

someone recently got a metallb setup working with Netmaker...need to look to see if it's on github

This is the setup I would like to have. K8s is currently not yet part of the network. Everything else is in place

How do I go about joining the K8s cluster which is behind CGNAT to the netmaker network

Also would it be possible to use kube-dns for name/service resolution for all the clients behind their own CGNATs

The new version (v0.19.0) should be suitable for this. The TURN server should detect that nodes are behind CGNAT and connect via relay. A good test case for our new system.

would the relay be a pod in k8s or a VM running alongside the k8s nodes/subnet?

VM, by default where Netmaker is installed

however you could also manually set up our regular "relay" to connect the nodes, and that could run in a pod if you need that

So in this scenario

Every host would have 10.20.30.2 as a GW to the docker network 172.30.40.0 and use the kube-dns server 172.30.40.9 as peer dns?

how would the return path from the k8s pods back to the netclient nodes work?

Hi, Is it possible to add my home computer as a node to a K8s cluster that is created via AWS EKS? I ask something similar was written here: https://k8s.netmaker.org/distributed-guides.html#wide-nodes

I am talking about Case 1 here (https://itnext.io/8-use-cases-for-kubernetes-over-vpn-unlocking-multicloud-flexibility-3958dab2219f) but instead of the VM being in Azure, it's kinda sitting at my home...