Yeah, internal for now lol

In the future there will be some routing magic occuring.

netmaker is intended to be installed on a machine with a static public ip.... you can do what you want but your are going to have to make a bunch of changes to your docker-compose file

question: if all your clients are on an internal private network, why do you need an overlaid encrypted network?

That's perfectly okay.

Internal testing to vet the product for my company lol

but in the future, clients will be on different networks

Correct-o

and what exactly is the problem with having the netmaker server with a public ip?

Well I'm testing it internally right now lol

what version are you testing? v0.20.0

Correct. Here's my docker-compose file. https://cdn.discordapp.com/attachments/975815541954609152/1111385627225751683/message.txt

whats in your Caddyfile

# Dashboard https://dashboard.test.internal.lan { tls /root/certs/fullchain.pem /root/certs/privkey.pem # Apply basic security headers header { # Enable cross origin access to *.test.internal.lan Access-Control-Allow-Origin *.test.internal.lan # Enable HTTP Strict Transport Security (HSTS) Strict-Transport-Security "max-age=31536000;" # Enable cross-site filter (XSS) and tell browser to block detected attacks X-XSS-Protection "1; mode=block" # Disallow the site to be rendered within a frame on a foreign domain (clickjacking protection) X-Frame-Options "SAMEORIGIN" # Prevent search engines from indexing X-Robots-Tag "none" # Remove the server name -Server } reverse_proxy http://netmaker-ui } # Netmaker Exporter https://netmaker-exporter.test.internal.lan { tls /root/certs/fullchain.pem /root/certs/privkey.pem reverse_proxy http://netmaker-exporter:8085 } # Prometheus https://prometheus.test.internal.lan { tls /root/certs/fullchain.pem /root/certs/privkey.pem reverse_proxy http://prometheus:9090 } # Grafana https://grafana.test.internal.lan { tls /root/certs/fullchain.pem /root/certs/privkey.pem reverse_proxy http://grafana:3000 } # API https://api.test.internal.lan { tls /root/certs/fullchain.pem /root/certs/privkey.pem reverse_proxy http://netmaker:8081 } # STUN https://stun.test.internal.lan { tls /root/certs/fullchain.pem /root/certs/privkey.pem reverse_proxy netmaker:3478 } # TURN https://turn.test.internal.lan { tls /root/certs/fullchain.pem /root/certs/privkey.pem reverse_proxy host.docker.internal:3479 } # TURN API https://turnapi.test.internal.lan { tls /root/certs/fullchain.pem /root/certs/privkey.pem reverse_proxy http://host.docker.internal:8089 } # MQ wss://broker.test.internal.lan { tls /root/certs/fullchain.pem /root/certs/privkey.pem reverse_proxy ws://mq:8883 }

Lol sorry, tried to format it and it failed to send.

lol

my recommendation would be to go back to the standard docker-compose file and make your changes in netmaker.env

So I tried that and it seems that docker-compose failed to take it anything from netmaker.env.

Also tried using

nm-quick.sh

to even just get it running and it stopped after

pulling config files

and you need to match what you have in the the Caddyfile to the compose/env.. eg in Caddy you have netmaker api listening on port 8081 but in the compose you did not specify a port

Lol jfc. I can't believe I didn't catch that. Thanks!

Okay, so trying this now, seems to be no joy with the env file

WARNING: The NM_DOMAIN variable is not set. Defaulting to a blank string.
WARNING: The STUN_PORT variable is not set. Defaulting to a blank string.
WARNING: The SERVER_HOST variable is not set. Defaulting to a blank string.
WARNING: The UI_IMAGE_TAG variable is not set. Defaulting to a blank string.
WARNING: The TURN_USERNAME variable is not set. Defaulting to a blank string.
WARNING: The TURN_PASSWORD variable is not set. Defaulting to a blank string.
WARNING: The EXPORTER_API_PORT variable is not set. Defaulting to a blank string.

But weirdly, if I echo $STUN_PORT, I get back the proper value.

Okay, so the fix was to build the netmaker.env file myself and symbolically link it to .env, even though it ignores netmaker.env and expects .env. lol

But that still didn't fix the netmaker-exporter issue where it's trying to connect to

ws://<what_it_thinks_is_its_external_ip>:1884

rather than what it should be connecting to.

I see in the doc that oracle cloud is not recommended. Is it still the case? Out of curiosity, what's the actual issue? After a quick search I found it could be something with iptables, but could anyone share more technical details about this?

Hello, I'm trying to do a fresh install of netmaker v0.20 and the install script always fails at "Pulling config files..." There are no errors, it just stops.

Okay so last spicy bit here. My netmaker-exporter is failing to connect to mq. Repeated

[netmaker] Fatal: could not connect to broker, token timeout, exiting ...
[netmaker-exporter] 2023-05-26 13:56:47 MQ Broker Endpoint  ws://mq:1884

However, netmaker itself does succeed in connecting to mq.