[NOOB] Connecting NAS dble ETH to LAN1 not accessible from LAN3

[cookiemonster]

just filter on LAN1 please, and ping from the laptop on that network.
If it is not appearing on the live log, the packet is not hitting the firewall. That simple.

[MarieSophieSG]

From the laptop, ping LAN3 interface 192.168.103.101
I don't see any such appearing in the log

But I see 192.168.101.116 (Laptop1) trying to hit 192.168.101.127 which is an IP leading to none ... strange to me, but maybe there is a rational ?

[MarieSophieSG]

just filter on LAN1 please, and ping from the laptop on that network.
If it is not appearing on the live log, the packet is not hitting the firewall. That simple.

Filter to LAN1 only
Laptop1 to ping LAN3 interface,
No line appearing in the log ... (waited a couple of minutes with ping still on)

[cookiemonster]

Then is not getting to OPN.
Worth remembering what is meant to happen:
Devices on the same netwkork i.e. on LAN1 will NOT go _through_ OPN. So all devices on that switch will only go through the switch, port to port. Unless you are enabling some routing funtions on that switch. If it is unmanaged, then is a moot point.

Devices on different networks i.e. on different interfaces of OPN will go from one to the other _through_ OPN. So a packet from say client A on LAN1 192.168.101.116 to LAN3 on 192.168.103.101 will go _through_ OPN and once all is logged in OPN, will appear there.

If it doesn't, then is not hitting OPN.
At that point you must go back to checking physical connections, interface setup on OPN and your switches.

Start breaking up the problem with this overview and go in a systematic manner.
Another suggestion: skip pings for a moment and try other type of connections. iperf, maybe a webserver, etc. Easy with a laptop on each end.

[MarieSophieSG]

Then is not getting to OPN.
Worth remembering what is meant to happen:
Devices on the same netwkork i.e. on LAN1 will NOT go _through_ OPN. So all devices on that switch will only go through the switch, port to port. Unless you are enabling some routing funtions on that switch. If it is unmanaged, then is a moot point.

Devices on different networks i.e. on different interfaces of OPN will go from one to the other _through_ OPN. So a packet from say client A on LAN1 192.168.101.116 to LAN3 on 192.168.103.101 will go _through_ OPN and once all is logged in OPN, will appear there.

If it doesn't, then is not hitting OPN.
At that point you must go back to checking physical connections, interface setup on OPN and your switches.

Start breaking up the problem with this overview and go in a systematic manner.
Another suggestion: skip pings for a moment and try other type of connections. iperf, maybe a webserver, etc. Easy with a laptop on each end.

Thank you
All connection are good (RJ45 IN, led ON, etc..)
All devices on each Interfaces are reaching out to the Internet through OPN
All Interface set to the same as LAN1 (naming, rules, ..)
DNS is autom
All switches are unmanaged, and WiFI AP router is set to bridge, unmanaged

Worth noting: I have access to NAS2 (LAN3) GUI from Laptop2 (LAN2) !!
This is my work laptop, and the only one device out of all which I don't need/want to access any NAS (or anything else on my network for that matter) ... aaarrgggg wwhhyyyy ?

iperf:

Code Select Expand

sophie@T440p:~
$ iperf -d 192.168.103.101
WARNING: option -d is not valid for server mode
iperf: ignoring extra argument -- 192.168.103.101
Usage: iperf [-s|-c host] [options]
Try `iperf --help' for more information.
sophie@T440p:~
$ iperf -c 192.168.103.101 -d
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  128 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.103.101, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
ERROR: expected reverse connect did not occur
tcp connect failed: Connection timed out
[  1] local 0.0.0.0 port 0 connected with 192.168.103.101 port 5001
sophie@T440p:~
$


[cookiemonster]

quick check before reading your last post properly. Is the problem to reach only one device on the other network or any and all (that you can tell of course) ?

[MarieSophieSG]

quick check before reading your last post properly. Is the problem to reach only one device on the other network or any and all (that you can tell of course) ?

Good question (to rule out the network but rather incriminate one host)

So far, apparently, only 1 Windows computer can reach out to other LANs
Laptop2 (LAN2) can ping NAS2 (LAN3) and browse to its GUI, can ping any LANs interface (.101.101; .102.101; .103.101)
Laptop2 can reach LAN2 interface, and it can reach WiFI AP GUI

while Laptop4, even though also win10 (on LAN3) can't ping other LANs, I therefore assume it won't reach any devices on these
Ping 192.168.101.101, 100% loss
Ping 192.68.101.116 (Laptop1) 100% loss
Ping 192.168.102.101 100% loss
Ping 192.168.102.116 loss

While the Linux and android devices can't
Laptop1 (LAN1) can't ping Laptop4; Laptop3 can't ping NAS2; can't ping Interfaces (other than its own)
Laptop3 (LAN3) can't ping Laptop1; Laptop4; can ping NAS2 (but can't reach its GUI); can't ping Interfaces (other than its own)
Android devices can't reach anything internal (on any LAN, including their own) neither can they browse to the WiFI AP GUI they are attached to
Laptop4 when booted to Qubes-os neither, but that OS is so secured, so far I didn't even mentioned it for networking tests

[MarieSophieSG]

Traceroute from Laptop1 to NAS2:

Code Select Expand


sophie@T440p:~
$ traceroute 192.168.103.118
traceroute to 192.168.103.118 (192.168.103.118), 30 hops max, 60 byte packets
1  * * *
2  * * *
3  * * *
4  * * *
5  * * *
6  * * *
7  * * *
8  * * *
9  * * *
10  * * *


Tracert from Laptop2 to NAS2

Code Select Expand


C:\Users\xxxx>tracert 192.168.103.118

tracing route to NAS653D [192.168.103.118]
over a maximum of 30 hops:
1  <1 ms  <1 ms  <1 ms 192.168.102.101
2  <1 ms  <1 ms  <1 ms NAS653D [192.168.103.118]

Trace complete.


[cookiemonster]

Right then. First recap.

So far, apparently, only 1 Windows computer can reach out to other LANs
Laptop2 (LAN2) can ping NAS2 (LAN3) and browse to its GUI, can ping any LANs interface (.101.101; .102.101; .103.101)
Laptop2 can reach LAN2 interface, and it can reach WiFI AP GUI

So that tells us your LAN2 has a firewall rule that allows to reach LAN1. One network good.

So we're back to LAN1, right ? LAN3 will be next.
So we need to view the firewall rules on this one. Compare to the known good. Share it here as before (lost track if is the one you shared already). And share your interface setup. Could it be set as not /24  I wonder.

For the purpose of diagnosing the network, leave IoT, mobiles phones, smart toasters, etc. out of the picture. If you have a device with a console like a laptop that you seem to have, just stick with them. Keep it simple.
Once problem solved, then you can start looking at those in the knowledge your firewall and rules are not in the way.

p.s. And on your iperf test. a) you did set the server in listening mode (-s), right? ;b) the error suggests there was no return so could be the missing rule on that interface to get the packets back to sender.
In fact, time to do it in pairs.

[cookiemonster]

Traceroute from Laptop1 to NAS2:

Code Select Expand


sophie@T440p:~
$ traceroute 192.168.103.118
traceroute to 192.168.103.118 (192.168.103.118), 30 hops max, 60 byte packets
1  * * *
2  * * *
3  * * *
4  * * *
5  * * *
6  * * *
7  * * *
8  * * *
9  * * *
10  * * *


Tracert from Laptop2 to NAS2

Code Select Expand


C:\Users\xxxx>tracert 192.168.103.118

tracing route to NAS653D [192.168.103.118]
over a maximum of 30 hops:
1  <1 ms  <1 ms  <1 ms 192.168.102.101
2  <1 ms  <1 ms  <1 ms NAS653D [192.168.103.118]

Trace complete.


Second one is nice and healthy. Shows hitting the OPN LAN3 interface before going out to the device on LAN2 interface.

The first one is not healthy obviously but is not reaching the interface. You need to check the interface second. First, the network stack of that laptop. Suggest you disable and re-enable to recreate the routes when it gets a fresh dhcp lease. If set manually, verify those and the gateway you have set. I thought I had mentioned that before.

[MarieSophieSG]

Right then. First recap.

So far, apparently, only 1 Windows computer can reach out to other LANs
Laptop2 (LAN2) can ping NAS2 (LAN3) and browse to its GUI, can ping any LANs interface (.101.101; .102.101; .103.101)
Laptop2 can reach LAN2 interface, and it can reach WiFI AP GUI

So that tells us your LAN2 has a firewall rule that allows to reach LAN1. One network good.

So we're back to LAN1, right ? LAN3 will be next.
So we need to view the firewall rules on this one. Compare to the known good. Share it here as before (lost track if is the one you shared already). And share your interface setup. Could it be set as not /24  I wonder.

I'm not sure I understand correctly ? Are you suggesting that automatic rules could be different from one LAN to the other ?
Based on what ? what is the parameters that leads to such decision ?
AFAIK, all three LANs are all the same, all with the 20-ish automatic rules and the two initial extras (to avoid "lambda :-p ) ones
I will try a side by side comparison then ...
All the exact same 23 rules, except LAN1 has a 24th self anti-lockout

For the purpose of diagnosing the network, leave IoT, mobiles phones, smart toasters, etc. out of the picture. If you have a device with a console like a laptop that you seem to have, just stick with them. Keep it simple.
Once problem solved, then you can start looking at those in the knowledge your firewall and rules are not in the way.

Sure thing !

p.s. And on your iperf test. a) you did set the server in listening mode (-s), right? ;b) the error suggests there was no return so could be the missing rule on that interface to get the packets back to sender.
In fact, time to do it in pairs.

iperf was set as shown in the code: -c (client) then IP, then -d (double / return)
The -s option is for serveur, taht's why I didn't use it, will try that

Code Select Expand


sophie@T440p:
$ iperf -s 192.168.103.101 -d
WARNING: option -d is not valid for server mode
iperf: ignoring extra argument -- 192.168.103.101
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  128 KByte (default)
------------------------------------------------------------


Been in that state for about 5min now ...

[MarieSophieSG]

Second one is nice and healthy. Shows hitting the OPN LAN3 interface before going out to the device on LAN2 interface.

The first one is not healthy obviously but is not reaching the interface. You need to check the interface second. First, the network stack of that laptop. Suggest you disable and re-enable to recreate the routes when it gets a fresh dhcp lease. If set manually, verify those and the gateway you have set. I thought I had mentioned that before.

All clients are DHCP (for now) since the fresh re-install.
Network boot is always disabled on my devices (never use it, so I took a habit to remove it from the boot options)

[cookiemonster]

> I'm not sure I understand correctly ? Are you suggesting that automatic rules could be different from one LAN to the other ?
They are logically identical but you might need to go and change the interface.
So say you have a rule on LAN1 interface. Then you clone it to use it on LAN2. You should then verify that the new rule has LAN2 as its interface that it applies to. The cloning won't know what you intended to use it for.
Please post them here instead of assuming.

> iperf was set as shown in the code: -c (client) then IP, then -d (double / return)
The -s option is for serveur, taht's why I didn't use it, will try that

This is just a clarification. When you do an iperf test you need two ends, a client -c and a server -s.

[MarieSophieSG]

> I'm not sure I understand correctly ? Are you suggesting that automatic rules could be different from one LAN to the other ?
They are logically identical but you might need to go and change the interface.
So say you have a rule on LAN1 interface. Then you clone it to use it on LAN2. You should then verify that the new rule has LAN2 as its interface that it applies to. The cloning won't know what you intended to use it for.

You can't modify the automatic ones, so you can't change the interface nor anything

Please post them here instead of assuming.

Not assuming, I did a side-by-side comparison, and did find that they are all 3 the same 23 rules, *except* for LAN1' 24th rule which is the anti-lock-out

All three attached

[cookiemonster]

Thanks they look correct.

>You can't modify the automatic ones, so you can't change the interface nor anything
I was referring to the cloned ones.

So now time to resume diagnosing LAN1.
Test from a device on LAN1 to a device on LAN3 and watch the live logs. Filter only on interface LAN1. Rules enabled logging. What do you see?