It seems that I can access my NS8 locally (of course), including services like webtop etc.
I can access my NS8 also over internet, on services I expose to the internet (again like webtop and port forwarding with my router).
I can access my NS8 if I use WireGuard VPN to my host (UNRAID) server.
I CANNOT access my NS8 when I try with my hardware (router-to-router IPSec VPN). All my network passes through the tunnel both sides. But unlike the cases above, using my IPSec VPN, I have no NAT, so a computer in side 192.168.0.X (for example) tries to access NS8 in side 172.17.0.X (for example) and I suspect NS8 BLOCKS access not from LAN.
Can I set NS8 to “know” about remote network (192.168.0.X in the example) and consider it safe?
At least, I believe this is my issue. I checked everything else and nothing should be blocking access to my NS8 (no router firewall both sides, they both expose each other’s network).
I don’t want to be forced to kill my hardware IPSec VPN and use WireGuard.
I prefer WireGuard for device-to-LAN connections, not LAN-to-LAN.
BTW I would also hope such firewall settings (if this is the issue after all) to be exposed to GUI, but for now I am willing to edit any config file you point me to.
Oh I have already found that.
But seems that those ports are open to LAN. At least this is what I think, because I don’t see anything else that could be possible.
Could someone help me on how to expose the open ports to another (specific) network?
There must be something in firewall-cmd to do that.
Don’t know much about it and unaware if it is what you need, but firewall-cmd allows users to assign interfaces to zones.
Zones are like a way to define a level of trust for network connections.
You can list default zones with:
firewall-cmd --list-all-zones
Get active zones with:
firewall-cmd --get-active-zones
…which also will show which interfaces are assigned to active zones (public, trusted, external…)
firewalld also allows to create custom zones.
The best source of information would be firewalld manual.
IIRC cockpit can handle firewalld rules, to some extend.
Thanks people. I already read those.
Seems that NS8 basically uses 2 zones and doesn’t use the others.
One is used for the “inside” (using the “internal” VPN network) and one for everything outside (so LAN is the same as something coming from my VPN or from outside using router port forwarding).
So my problem must lie somewhere else?
I cannot find where for the life of me.
I still suspect that it could be some “lost” NAT.
Remember, NS8 come from an internal intra-node network, not accessible outside. Then they NAT to whatever LAN address NS8 is.
If a request comes from the Internet (and a port is forwarded), then NS8 doesn’t need to know the public address that requested the service. Router handles that.
If the request comes from the LAN, then NS8 knows about this LAN it has already done NAT for it.
If I use (as I do) hardware IPSec VPN, then maybe the service request to NS8 arrives with the remote LAN IP. And NS8 doesn’t know how to reply to it. It is an unknown network.
That’s a theory.
I wish someone with better grasp than me, in NS8 networking could help.
Maybe something to help me trace if something arrives to NS8?
(and just doesn’t know the return path)
If this is a generic issue (can someone replicate it?) then it is pretty important.
Think if NS8 doesn’t go through router-to-router VPN! That’s pretty bad.
I do have a classic “suspect”, maybe you could confirm some simple questions:
Can NS8 ping / access anything on the VPN LAN at Site2 (For lack of a better name).
Can the NS8 host be pinged or accessed (eg via SSH) from Site2
The above may help to isolate if the host itself works with your IP-Sec VPN and the issue lies within NS8, or both host and NS8 can’t use the VPN.
It might also be worth printing out the routing table of the NS8 host itself - is there any entry pointing to Site2 via VPN?
Does your Site2Site IPsec VPN use a “VPN Network” like OpenVPN or Wireguard does?
(It is possible with IPsec, but not commonly used…).
I’m assuming the VPN connection is maintained by your default gateway, but this may not be the case. I also have situations where a third box handles the VPN, but routing must be correctly entered on all relevant routers.
I think I mentioned that I couldn’t even ping NS8 from site 2 - but anyway, yes I cannot.
Good thinking, I never tried the opposite! Indeed from NS8 console I cannot ping anything in site 2.
My site2site IPsec VPN, after VPN establishes does normal routing of a subnet to another subnet. Also each other knows the other side’s DNS and even NETBIOS, but those are beside the point because we don’t even have IP connectivity with NS8 (from site 2).
I can ping everything else from both sides, even “dummy” IoT devices. This is why I tend to believe that NS8 is the issue.
Asking about routing table, I am going to expose my subnets (they are lab after all), because this is interesting…
Site 2 uses 172.17.4.0/24 and Site 1 (where NS8 is) uses 172.17.2.0/24.
Here is what “ip route list” output in NS8:
172.17.2.1 is my site 1 router.
172.17.2.20 is NS8.
I have no idea what 172.17.2.221 is, is in my DHCP space.
Digging a bit, I see it is NS8 too!!!
It has the same MAC and if I pause NS8 VM, it doesn’t respond any more! Why does NS8 use a second IP? (is it anywhere in the docs?)
I am guessing that this 172.17.0.0/16 is part of the problem btw.
Even if you could ping from site2, NS8 would not be able to “answer” to those pings…
NS8 normally does not use a second IP. So finding more about this would be interesting.
I am quite sure this is THE problem or a major part of it. This probably has to do with the underlying OS used for NS8 (Rocky?).
The size of the subnetmask defines the size of the network. If site2 uses a similiar subnet (It does: 172.17.4.0/24), we have our issues, as no server will “route” anything destined to a local subnet.
Probably the first step would be finding out where, why and how did the 172.17.2.221 appear…
Second step may be checking the network config of the underlying host system (I use Debian) and see if you can find the 172.17.0.0/16 defined anywhere. Correct this!
→ In the old days, IP networking were defined as A, B or C class networks, A using a 10.0.0.0/8, B using a 172.16.xx-172.31.255.255/16 and C using 192.168.x.x/24, at least for the “private” space set aside in the RFCs.
These subnets could always be subnetted. But some OS or systems still have the /16 subnet cached somewhere - not correct! (Windows still does this, if using a 172 IP…).
Good Luck - this seems to be one of those issues where that can matter!
My 2 cents
Andy
PS:
My Home NS8 (Debian VM on Proxmox) uses the following:
I am using the “stock” preset Rocky VM as I downloaded from NS site.
I haven’t manually defined .221 anywhere for sure.
Seems like a second interface exists that got IP from DHCP?
I will look into it.
I know what netmask does and I have manually defined my 172.17.X.Y networks to be class C (manually), everywhere. I had no issue before NS8 (even with NS7). This /16 kills things.
I think the guy who built that VM should step in the thread. @dnutan can we find him?
I can see that, and just wanted ti signal that by including my own NS8 network config also using a 172 C-Class, showing we both understand the networking concepts behind.
But the /16 signaled a warning red light to me!
The question remains: Who or What is handing out /16 via DHCP?
The VM having an additional NIC is one thing, but a DHCP (or rogue DHCP you don’t know about) handing out /16 is even worse!
I like the mental image of an OS “booting” better than one of an OS “stepping”…
The VM has a single “NIC”.
I am not blaming anybody, but in case this happens somewhere in the “stock” image, we need to identify it and put it in the instructions and FAQ etc.
I found it.
I run nmtui and my “wired connection 1” has a mask of /16!
I didn’t set it like that, I don’t know what reset it to /16.
Edited back to /24, rebooted and… magically (well as expected), everything works!
Now about that .221 IP. In nmtui, under Ethernet I have except “Wired connection 1”, also “System eth0” and “ens3”. The last two, are “automatic”. Do I need those?
Wireguard has it’s own section and I don’t touch it.
For completion, I found why it used /16 and I found about IP .221.
When you don’t supply a netmask, the system “assumes” what you need to put. Since 172. is normally a class B network, it assumed /16. I needed to manually say /24. (so I did and it fixed everything)
The .221 came because when I first defined the network, I set an IP, DNS, GW, but left it “automatic”. Don’t assume that automatic is “stopped” by supplying a manual IP. It just gets two IPs! One manual, one DHCP!
, j’accuse - 1919), consider if the IP could have come from a migration, hypervisor, etc…