Jake McGinty

Hey @amarao - haven't forgotten about this issue, just waited on addressing it until 1.5.0 was out the door. Seems like we'll need to collaborate with ureq to make this...

@amarao does that mean that there was both an `/etc/innernet-server/foo.conf` and an `/etc/innernet/foo.conf`? Otherwise, `innernet` should say that no interface config was found when running `innernet fetch`.

Added more details in https://github.com/tonarino/innernet/issues/115#issuecomment-882433652 that help describe our current state of NATitude.

Here's how I'm currently thinking about the problem and working on it: ## Phase 1 (STUN) #118: Add awareness of the likelihood of a working peer endpoint and don't overwrite...

I've given a shot at not bringing in new dependencies, and implementing an ICE-lite protocol in #134 to assist with NAT traversal (or, rather, avoiding the need for holepunching all...

Yeah, we will probably just want a guide/quick tool to export "vanilla WireGuard" config files for devices that don't have support for the innernet client.

Yeah, in this case the limitation is that peers can't have the same name - "node-01" would have to be unique on the network. The reason we didn't add CIDRs...

Yeah, I'd say if you have lots of existing enterprise-type infrastructure with complicated domain/DNS stuff, innernet doesn't have a lot of built-in integrations so you'll find yourself having to write...

Reopening this as a tracking issue for CIDRs to be hostname-compatible. I'm going to start enforcing that newly-created CIDRs be hostnames, and will start adding warning dialogs and renaming functionality...

@bonedaddy try enabling more verbose output and see if it provides better information: ``` ExecStart=innernet-server -vv serve %i ```