Ihave a client with a network 192.168.175.x/24 and a secondary network 172.16.x.x/16.
The default Gateway is 192.168.175.1. To reach the 172.16.x.x network a route needs to be added manually.
Using Static Routes this works for the NethServer.
Background:
One Client Notebook needs to work time to time in the 172.16.x.x network, and still have access to files on the Nethserver.
The NethServer can be reached, and awnsers to pings. The NethServer-AD, with the IP 192.168.175.11, is not reachable. I think the AD ignores any additional routes, that the Nethserver honours…
How can I check this?
Ping from the Nethserver to a host in 172.16.x.x works. Both ways. But not with the NethServer AD…
Hi
The NethServer itself has only one Interface (192.168.175.20), the AD is using the physical Interface (Br0) as Bridge (192.168.175.11)
There are two gateways in that LAN, 192.168.175.1 (Default Gateway) and 192.168.175.2.
Both routers do routing, but not more.
The Network 172.16.x.x is behind the 192.168.175.2 Router.
The NethServer uses the entry in “Static Routes” and finds it’s way to the 172.16.x.x network.
This can be verified by pinging the client or server (works both ways).
The AD seems to ignore this entry and only uses the default gateway, meaning these packets get routed to the internet and not to 172.16.x.x…
The Default Gateway does NOT forward traffic to 172.16.x.x as only a couple of boxes need this.
The client in 172.16.x.x can ping the Nethserver but not the AD. On the LAN the AD can be pinged.
The result is that the Network Drive is accessible, but not the Authentification befind - and NethServer needs AD to do auth on Shares… So no access!
Clarified a lot.
I suppose that the “real solution” of the issues, have ONE gateway connected to three network segments as RED, 192.168.175.0 and 172.16.0.0 is not feasible in any way…
NSDC/AD is a sort of virtual machine, so “not honor” the route configure into Nethserver is correct by design: needs another ip address of 192.168.175.0 and the creation of the bridge, but the routing table is not editable via NethGUI (wisely, IMVHO). In case of unification of the gateways route should be promptly removed…
Anyway… You can run commands into NSDC, as stated by docs. https://docs.nethserver.org/projects/nethserver-devel/en/v7/nethserver-dc.html#running-commands-in-nsdc
even add a static route.
which should solve your issue without hassle but I do not recommend it, because if not well noted and explained into installation documentation this could run into problem if any major network configurations goes on line, like adding another interfaces on default gateway or address space change.
I can bet a small beer that this “fast” solution will be surely tried, therefore… backup before route
Have a nice sunday.
I also would prefer a correct solution, covered by “best practices” in any knowledgeable persons opinion.
If NethServer did any for of Routing, I’d agree with your suggestion. However, NethServer is designated as Server and AD, but not any form of routing.
As routing is done by some other box (The default router), logic dictates THAT box should do this routing and route any packets to the second router, like it does for itself.
Here’s where VoIP, MultiWAN, VPNs and other stuff come into the equation and things become ugly - or as the saying goes: “Here be dragons…”.
Since this network is time limited by termination of location end of 2020, and is my creation, I think I can take the “risk” of adding a route and adding this into the documentation.
But thanks for the pointers to the NSDC Doku…
PS: Any suggestions as to the Route Add problem? Like making things Persistant or is Templating needed, like other NethServer stuff? Like command route not available…
Note: All components are backuped daily, and I can easily do a backup within NethServer and underneath, as it’s running in ProxMox…
I hope this helps and please come back for feedback
Well… yes and no.
On the theoretical side of this thing (is the only one that i can see) it’s just a matter of one phisical interface available into the “main gateway” which should be configured accordingly with the subnet used (172.16.x.x), add a bunch of firewall rules if necessary and… bada bing bada boum the solution is served. Of course, a prior backup is necessary.
Of course this is my experience with different appliances (Zyxel, NetGear, TpLink, Watchguard) and firewall distros project (M0n0wall, Endian Firewall, NethServer, IPFire) that makes life easy adding interfaces on subnets. Maybe your main router do not make life easy in the same way…
Question should be routed to @dev_team…
As far as i can rememeber @giacomo wrote that many aspects of NSDC are pre-cooked when the container is created and not influenced by templates, or updates of the packages.
Also, templates are necessaries for avoid that the read of the configuration DB destroy the configuration of… services, not routing table.
Anyway: the creation of the routing table is part of the boot process, so i should assume that at the first reboot the static route should be added again, but I cannot guarantee one way or another. It’s still a “quick and dirt” solution.
Problem on the Firewall side: we need too many subnets, partly historically. Our Boxes support 4 Interfaces, we’d need 6-7 ideally…
Problem on the budget side: This project, now running for 12 years, is time limited by termination of location. The 20 y lease on the building is not been renewed, which makes things very difficult to relocate, as we’re talking about a Hotel (!). So this stuff has to run 16 Months more, with as little expenses as possible.
Problem on the software end: the command route isn’t available, as this is a Container within NethServer, was to be expected.
Another thing: This WAS running before the last Samba update 3-4 days ago, afaik…
According to nsdc green.network template, only the default GW is set in nsdc network configuration. Static routes are not pushed to nsdc network configuration.
A workaround could be adding the route to your default GW, or implementing a template-custom of /etc/e-smith/templates/var/lib/machines/nsdc/etc/systemd/network/green.network/10base.
Hi
Just wanted to tell you, your tip with the custom template worked like a charm!
I basically changed the default gateways IP to 192.168.175.2, expanded the template and restarted the NSDC.
The NSDC was pingable from the outset, but as usual, the windows notebook needed a reboot.
After that all network drives were working as usual.
Looking for the same thing. I occasionally need to connect to AD domain (10.50.0.1) from my VPN subnet (10.40.1.0/24). Samba shares are accessible, but AD NSDC container isn’t pingable.
Your template-custom would be awesome.
nevermind…
So create the custom template as davidep mentioned.
In the template file: add the default gateway manually by replacing the $gateway variable with your default gateway, in my case 10.50.0.3.
[Match]
Virtualization=yes
Name=host0
{
use esmith::NetworksDB;
use Net::IPv4Addr qw( :all );
my $ndb = esmith::NetworksDB->open();
my $bridge = $nsdc{'bridge'} || die ("[ERROR] There is no network bridge for NethServer domain controller");
$OUT = "[Network]\n";
$OUT .= "Address=" . $nsdc{'IpAddress'} . '/' . ipv4_msk2cidr($ndb->get_prop($bridge, 'netmask')). "\n\n";
my $gateway = $ndb->get_prop($bridge, 'gateway');
if(!$gateway || scalar $ndb->red()) {
# if the gateway is defined on a different network/interface, set our green IP:
$gateway = $ndb->get_prop($bridge, 'ipaddr');
}
$OUT .= "[Route]\n";
$OUT .= "Gateway=10.50.0.3\n";
}
Or you can set $gateway=“10.50.0.3”; before.
And NSDC AD container IP is no longer isolated from any other subnets.
A better option might be to comment out or remove the gateway section and replace it with a simple $gateway=your_gateway_ip_address
Original 10base file
[Match]
Virtualization=yes
Name=host0
{
use esmith::NetworksDB;
use Net::IPv4Addr qw( :all );
my $ndb = esmith::NetworksDB->open();
my $bridge = $nsdc{'bridge'} || die ("[ERROR] There is no network bridge for NethServer domain controller");
$OUT = "[Network]\n";
$OUT .= "Address=" . $nsdc{'IpAddress'} . '/' . ipv4_msk2cidr($ndb->get_prop($bridge, 'netmask')). "\n\n";
my $gateway = $ndb->get_prop($bridge, 'gateway');
if(!$gateway || scalar $ndb->red()) {
# if the gateway is defined on a different network/interface, set our green IP:
$gateway = $ndb->get_prop($bridge, 'ipaddr');
}
$OUT .= "[Route]\n";
$OUT .= "Gateway=$gateway\n";
}
Sry about the late response, but I was two hours on a train, mobile ran out of power.
I did have a charger along, even a backup ext battery, but left the cable at home.
This is my custom template:
[Match]
Virtualization=yes
Name=host0
{
use esmith::NetworksDB;
use Net::IPv4Addr qw( :all );
my $ndb = esmith::NetworksDB->open();
my $bridge = $nsdc{'bridge'} || die ("[ERROR] There is no network bridge for NethServer domain controller");
$OUT = "[Network]\n";
$OUT .= "Address=" . $nsdc{'IpAddress'} . '/' . ipv4_msk2cidr($ndb->get_prop($bridge, 'netmask')). "\n\n";
my $gateway = "192.168.175.2";
if(!$gateway || scalar $ndb->red()) {
# if the gateway is defined on a different network/interface, set our green IP:
$gateway = $ndb->get_prop($bridge, 'ipaddr');
}
$OUT .= "[Route]\n";
$OUT .= "Gateway=$gateway\n";
}
Basically the same as above, just i put in the gateway a bit earlier in the code…
