topology:
192.168.32.1: ROUTER = gateway with dhcp server, promotes 192.168.32.7 and 1.1.1.1 as DNS, also provides itself a miniature DNS service (<10 items as local DNS fallback)
192.168.32.6: nethserver instance, ovpn configured
192.168.32.7: nethserver nsdc controller
192.168.32.x: clients
From the beginning I encountered a small DNS glitch in my NS instance: an error stating that one or more DNS servers don’t answer. (addresses like 1.1.1.1, 9.9.9.9, 4.4.4.4, 8.8.8.8 …) I didn’t bother about this too much. Everything seemed to work somehow.
Lately I sometimes get a connection to my NS instance, when trying to connect to the router by IP in a browser. Thus, not the config screen of the router appears, but the website of the NS. This happens sometimes, at maybe 50 percent chance, not always. Which is weird. (I never could access local devices via ovpn tunnel, except xx.6 and xx.7, although I tried to set up a route and trusted network. Don’t know if this is relevant.)
But, most important: I cannot resolve any external domains, when propagating xx.7 as first DNS via the routers dhcp. Local DNS at xx.7 can’t resolve them for sure, but it stopped forwarding the request to another DNS. (Clients receive both DNS with the dhcp lease.)
So I have three questions:
Why do I have trouble with DNS servers of high availability?
Why does my NS instance deliver content when I ask for the router?
Why does my nsdc DNS not forward requests for external sites?
Where to look? - I am not a pro, just an enthusiastic end user, so verbosity is appreciated.
First make sure there is only 1 DHCP server - you need only 1 DHCP per IP segment (192.168.32.0/24)
ROUTER 192.168.32.1 should promote itself as primary DNS and 1.1.1.1 as secondary DNS.
If it promotes 192.168.32.7 as DNS, then 192.168.32.7 will have itself as DNS => endless loop ???
ad 1:
There are two candidates for DHCP service in the subnet, the router and thte NS. I activated DHCP in the router, and I think it’s inactive in NS. There’s no main DHCP switch in cockpit and it is not listed under “services”. The DHCP Tab itself shows no IP reservations, so I assume it is inactive.
One funny thing happens when searching the network in the NS DHCP Tab:
x.x.32.1 MAC of router neth.server.gsr
x.x.32.7 MAC of nsdc (unknown, locally administered)
x.x.32.16 MAC of router Draytek (router manufacturer, this is a VPN connection to the router)
and a few others.
The description of the first entry is wrong, I don’t know where it comes from. And and entry for x.6 (which is neth.server.gsr) is missing. In the router DNS, neth.server.gsr resolves to x.6, not to x.1
ad 2:
Since I use the nsdc as ADC I need to promote it as DNS for my clients. I also was thinking about some kind of a request loop. I would expect either the nsdc DNS to forward requests to another DNS (maybe one of those I can enter in NS cockpit) or the clients to try the second DNS if the first (nsdc DNS) cannot resolve it. But little I know about these things.
[root@neth ~]# route
Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
10.147.239.0 0.0.0.0 255.255.255.0 U 0 0 0 tunbackovpn
192.168.1.0 10.147.239.2 255.255.255.0 UG 0 0 0 tunbackovpn
192.168.32.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
192.168.32.0 0.0.0.0 255.255.255.0 U 0 0 0 tungsrovpn
192.168.33.0 0.0.0.0 255.255.255.0 U 0 0 0 tunrw
The default gateway seems missing?
The old dashboard shows 192.168.32.1 as gateway for green. It also tells me, that DHCP is not checked on green (the only interface).
The old interface has a different view on the gateways as well (diagnostics-network route):
10.147.239.0/24 dev tunbackovpn proto kernel scope link src 10.147.239.1
192.168.1.0/24 via 10.147.239.2 dev tunbackovpn
192.168.32.0/24 dev br0 proto kernel scope link src 192.168.32.6
192.168.32.0/24 dev tungsrovpn proto kernel scope link src 192.168.32.1
192.168.33.0/24 dev tunrw proto kernel scope link src 192.168.33.1
I added a route to green interface:
target: 0.0.0.0/0
router: 192.168.32.1
metrik: (nothing)
Now routing displays a default route again, and connects to the outside world. However the router IP still has a reverse revolving to neth.server.gsr, the name of the NS instance. (The wrong name is displayed as router). How can I find the culprit?
It may be obvious to you, but I still have no idea about the necessary steps for a right configuration. E.g. the router ip still is answered by the NS webinterface. The second last entry here seems odd:
[root@neth ~]# route
Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
default router.gsr 0.0.0.0 UG 0 0 0 br0
10.147.239.0 0.0.0.0 255.255.255.0 U 0 0 0 tunbackovpn
192.168.1.0 10.147.239.2 255.255.255.0 UG 0 0 0 tunbackovpn
192.168.32.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
192.168.32.0 0.0.0.0 255.255.255.0 U 0 0 0 tungsrovpn
router.gsr 0.0.0.0 255.255.255.255 UH 0 0 0 br0
192.168.33.0 0.0.0.0 255.255.255.0 U 0 0 0 tunrw
Network topolgy is as simple and straight forward as I wrote in posting #1. Everything is connected to a SOHO router. Drawing it would not display additional information. If you need to know anything, I will do my best to provide it.
In desparation, I yesterday ruined the configuration. Now I cannot connect to my NS instance anymore (http/ssh/smb/ping). However I can still ping to nsdc container from a LAN client.
I can physically access the NS server and log in. Services are up and running (tested systemctl status of httpd and smbd).
I will post my last cli commands and the outputs of route and ifconfig in next post, first I need to sort out the desk to work on. I will need to retype everything.
I am very grafeful, if I could reestablish connectivity to the machine.
On the x.6 machine in network is there a valid gateway set also your previous issues could (not definately though) be something simple like DNS being cached somewhere hence possibly returning an old ip
the output for route shows the setup on x.6 machine.
I assume there is no valid gateway, but I don’t know how to set it.
I understand the last entry of “route” as: route requests for router.gsr (192.168.32.1) to 0.0.0.0 (local machine). This entry was automatically generated by the system, not by me.
