[Nextbox]Using with vodafone / no ipv6

hey folks,

want to set up my fresh delivered nextbox but failed so far. i strayed a bit through docs and the forum but yet cannot find what is wrong so lemme present what i got, hope for your help :slight_smile:

(from nextbox app dialog)

  • DynDNS (DEDYN) is working for ipv4
  • DynDNS (DEDYN) is not working for ipv6
  • Reachability waiting to be tested ← this step never ends in a result
  • HTTPS / TLS is activated

so far so good. Without any port forwarding, i reach my routers homepage - not freaking ideal, i know, but at least i can reach port 80 on my dns address. With port forwarding activated it simply times out.

but there is more - if i try to open nextbox.local i get also a time out pointing on the DNS address … either there is something messed up in the config or … well - is ipv6 mandatory? my router does not have a DNS rebind feature - did i missed something?

Greetings and thanks,

J

EDIT: From out of my local network, it is reachable - what the heck? oO

Did you open both ports 80 + 443 as documented here: Port Forwarding & Firewall Configuration — Nitrokey Documentation

yes - and it kinda works - at least i can logon, allthough i receive problems on client (app) side - but this should not be the topic here. Probably it is now … working?!?

Do you use your public domain for all your clients? Means your dynamic DNS domain, like https://foobar.dedyn.io, anything else might confuse your clients.

yes i do - but i cannot sync anything, but this might be an configuration issue - so allthough i receive errors on config page it is ok?

mmmh, sync should work without issues, that’s weird, any errors on that?

Further it’s not clear to me which “config page” you are referring to, can you be more precise please and also please paste the error, because it’s hard to guess which one you mean here :wink:

Did you check the FAQ? Frequently Asked Questions — Nitrokey Documentation

I have the exact same problem as the OP.

In my case, for some reason that can’t be changed, I have two routers in series:

ISP router — internal router ----------- nextbox
|
|----- client

I have port forwarded 80 and 443 on both routers. ISP router forwards both ports to the internal router (static IP). The internal router forwards both ports to the nextbox (also a static IP).

The dynamic dns was set-up. IPV6 test from within the nextbox fails, https/TLS has been set-up.

From the client, if I connect to nextbox.local, I reach the nextbox. If I connect to myname.dedyn.io, I get a time out.

From the client, if I VPN outside my network, and connect to myname.dedyn.io, I reach the nextbox!

I was trying to wrap my head around this, thinking it was an ipv6 setting in my network, but it seems the ipv6 is not required from outside the network. Is ipv6 just absolutely required inside the network?

My internal router is a ubiquiti er-X with hairpin NAT enabled. From my limited understanding of how that works, upon resolving dns to itself, the router should happily give access to the nextbox using the url and resolving to an internal address, right?

hey @cbkiyanda,

Generally IPv6 is only required, if you have no proper WAN (Internet) IPv4 address, this is e.g., not the case, if you have a DS-Lite connection (from your ISP). If you have a full so-called dual stack ISP connection, there is no need for IPv6. For your particular setup a proper IPv6 configuration is not trivial because the ISP router would have to enable prefix forwarding and the internal router would need properly assign these IPv6 addresses to its clients.

Especially, if https/tls is set up, then your NextBox was (at least) during this step (enable tls) available/reachable from the internet, without being reachable you would not be able to acquire the certificate.

From this drawing it makes sense that your client cannot connect to the nextbox using myname.dedyn.io as this would require both routers to have hairpinning enabled. Because this is what hairpinning does, it just enables clients from behind the same nat to connect to each other using a WAN address (e.g., myname.dedyn.io). This might be the reason why enabling HTTPS worked (your nextbox is available from outside the network) but you client is not able to connect to the nextbox via the global address (myname.dedyn.io) because the first NAT (your ISP router) seems to not support hairpinning nat. On top of that I can’t really tell if hairpinning still works for stacked NAT configurations as you have one, so even if both routers support hairpinning NAT I would not promise that it will work.

best

Unfortunately, the formatting screwed up the topology but failed into something that made sense. The actual network interconnections are (in vertical mode this time to not get tripped up by removed whitespace):

ISP router
|
|
Internal router------netbox
|
|
Client

This being said, I see your point about both routers possibly not supporting hairpin NAT. I’m still surprised of that’s the issue. I would expect that, without hairpinning on the ISP router, the DNS would resolve to the ISP router’s outside IP. The forwarding there would send packets to the internal router and back, so the path end up being

Client < > internal router <-> ISP router <-> internal router <-> netbox

I’ll see if I can figure out how to set a static route on the internal router so it just skips DNS for internal requests. There has to be a way to do something like that…

Hey,

okok, understanding the picture now, but ok, still the point is valid I believe,
Generally chained NATs are painful, frankly I am just guessing that this might be the issue, my experience with chained NATs is also very limited. But overall this should clearly work…

Some port-forwarding settings allow setting the origin, maybe you’ll have to add the local-ip range there, because obviously it in general works (because of the enabled TLS) for WAN connections. Maybe hairpinning isn’t really the real issue here.

Ok, I got it to work. The solution was static dns mapping. To get back to the original poster’s point, I’ll offer the following answer:

If:

  • you have port forwarding successfully set up for ports 80 and 443<
  • you have dynamic dns setup
  • your nextbox is accessible from outside your network using the dynamic domain name
  • your nextbox is not accesssible from inside your network using the dynamic domain name, but is accessible directly using the IP
    then:
  • on your router, set a static host map (basically a static dns entry that gets returned instead of pinging a dns server) that matches myname.dedyn.io → 192.168.1.x (substitute the correct dynamic dns name and the correct IP of your nextbox)
  • make sure the dns forwarding on your router is “local” (not sure if this is a standard naming). Basically, when your clients connect to the router, make sure they use the router itself as a dns server and they do not use an outside dns server

This way, your router will return the lan IP of the nextbox when a lan client queries the host name. My understanding is that hairpin NAT should take care of that. In my case, it’s possibly not working because of the daisy-chained NATs. In the OPs case, it may not be working just because the router doesn’t implement hairpin NAT or has a bug or something.

Note, specific to my case and possibly not the OP’s case: I’m using an ubiquity er-X, which requires activating dnsmasq. By default, dnsmasq is NOT the dhcp server and the standard setup does not handle the static host mapping, for some reason. It was many hours of running around to finally understand this. I ended up following instructions here: https://help.ui.com/hc/en-us/articles/115002673188 to (1) enable dnsmasq and (2) set the static host map for internal queries. I have a hunch that people who buy a nextbox may, more frequently, buy more professional equipment/replace router firmware etc. This information may be of use to some.

1 Like