Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have a debian 10 server connected to a network via static IP. The network consists of some workstations that are local with respect to the server (they're connected to the same switch) and some workstations that are remote (connected to a fiber optic network). The other workstations are windows-based.
It looks something like this:
The problem is:
- I can ping the server from any workstation
- I can ping any workstation (including remote) from the server
- I can ping any workstation from any remote workstation (and vice versa)
- I cannot ping the server from any remote workstation
I have excluded:
- the switch blocking ping requests (although it's managed, it's set up to let any traffic on the network)
- IPv6 is disabled on the server
- hardware (swapped different NICs)
- windows related stuff (disabled firewall, uninstalled antivirus etc)
Interfaces:
Code:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
allow-hotplug enp1s8
iface enp1s8 inet static
address 172.16.30.23
netmask 255.255.0.0
network 172.16.30.0
broadcast 172.16.30.255
up ip route add 172.16.30.0/24 dev enp1s8 table enp1s8
up ip route add default via 172.16.30.254 dev enp1s8 table enp1s8
up ip rule add from 172.16.30.23/32 table enp1s8
up ip rule add to 172.16.30.23/32 table enp1s8
allow-hotplug enp1s0
iface enp1s0 inet static
address 172.16.10.23
netmask 255.255.0.0
network 172.16.10.0
broadcast 172.16.10.255
gateway 172.16.10.254
up ip route add 172.16.10.0/24 dev enp1s0 table enp1s0
up ip route add default via 172.16.10.254 dev enp1s0 table enp1s0
up ip rule add from 172.16.10.23/32 table enp1s0
up ip rule add to 172.16.10.23/32 table enp1s0
(There's actually two NICs, two separate networks, but the other one works fine)
Routing table:
Code:
#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#
#1 inr.ruhep
1 enp1s8
2 enp1s0
I'm thinking maybe there's an issue with the server, although as far as I know debian doesn't come with an active firewall.
You could compare tracepath (or traceroute) results from remote workstation to server, and remote workstation to workstation perhaps. Examine the routing tables more completely.
Quote:
I'm thinking maybe there's an issue with the server, although as far as I know debian doesn't come with an active firewall.
That doesn't make sense if you take into account the OP's comments...
Quote:
The problem is:
- I can ping the server from any workstation
- I can ping any workstation (including remote) from the server
- I can ping any workstation from any remote workstation (and vice versa)
- I cannot ping the server from any remote workstation
It is very odd that it responds locally, but not from outside. Many of the tutorials on the internet use iptables to do this... but that is certainly not your issue here.
This should show "0":
Code:
$ cat /proc/sys/net/ipv4/icmp_echo_ignore_all
If it does, then there might be some setting or conflict in your router.
I made some slight progress. I found out that the server might only accept connections from IPs from 172.16.10.x network. Anything outside of it is blocked. That's true for the other interface as well.
The remote workstations have different IPs (172.16.122.x). It's technically the same network with the same mask, but I think there's something missing from the routing table.
I made some slight progress. I found out that the server might only accept connections from IPs from 172.16.10.x network. Anything outside of it is blocked. That's true for the other interface as well.
The remote workstations have different IPs (172.16.122.x). It's technically the same network with the same mask, but I think there's something missing from the routing table.
Yes, I missed this before, but if you examine the interface IP assignments, they are BOTH in the same /16 subnet space. Any reason for that? You should know that the broadcast address is defined as the last address in a subnet, so for both enp1s8 and enp1s0, this would be 172.16.255.255 (normally no need to explicitly define).
It would make more sense to change the subnet masks to /24 (255.255.255.0).
In any case, currently it's likely that a ping from 172.16.122.x will arrive via the gateway, and not return via it, since the chosen subnet mask means the source IP address is determined as being within the same network, so no routing needed, and hence no reply.
Yes, that is true, although the subnet is the same over the network, so I shouldn't be able to ping any 172.16.10.x machine from 172.16.122.x, but I can.
The networks were set up by a third party and we were given IP assignments for the workstations. Unfortunately, they chose to have it in the same /16 subnet. The two networks are supposed to be completely separate and should not be joined through this server. When I initially set up the interfaces, I got a lot of weird behavior hence why I did the routing table. But I don't quite understand how it works.
Last edited by bogdanc2011; 06-03-2020 at 03:14 PM.
#1. I can ping any workstation (including remote) from the server
#2. I cannot ping the server from any remote workstation
#1 proved that in fact there was two way communication between remote and server. Ping is generally a poor way to test communications as more and more ping is being blocked by default.
Are they separated by a router?
<172.16.122.x>Router<172.16.10.x>
Yes
Quote:
#1 proved that in fact there was two way communication between remote and server. Ping is generally a poor way to test communications as more and more ping is being blocked by default.
Well, the server is an NTP server, so if ping doesn't work there's a high chance that time synchronization doesn't work. And it doesn't.
I changed the netmask to 255.255.255.0 and I get the same issue. I also commented the broadcast and network sections.
ip route:
Code:
default via 172.16.10.254 dev enp1s0 onlink
172.16.10.0/24 dev enp1s0 proto kernel scope link src 172.16.10.23
172.16.30.0/24 dev enp1s8 proto kernel scope link src 172.16.30.23
Isn't this line basically telling "route all traffic from 172.16.10.x" to enp1s0, but ignore traffic from other IPs?
Code:
up ip rule add from 172.16.10.23/32 table enp1s0
EDIT: I remember I did the routing to prevent computers from one network to connect to the other network. But I think that by doing that, I also prevent 172.16.122.xx computers from connecting to the server.
Last edited by bogdanc2011; 06-09-2020 at 03:00 AM.
Isn't this line basically telling "route all traffic from 172.16.10.x" to enp1s0, but ignore traffic from other IPs?
Code:
ip rule add from 172.16.10.23/32 table enp1s0
No, this rule (policy-based routing) means that all traffic with the 172.16.10.23 source IP address will use the “enp1s0” routing table instead of “main” one. Likewise, the following refers to packets with the destination address of 172.16.10.23 being routed via the "enp1s0" routing table...
And the server works as expected. I can connect from 172.16.132.x computers.
But then if I add the routing, it stops working from those IP addreses:
Code:
allow-hotplug enp1s8
iface enp1s8 inet static
address 172.16.30.23
netmask 255.255.0.0
network 172.16.0.0
up ip route add 172.16.30.0/24 dev enp1s8 table enp1s8
up ip route add default via 172.16.30.254 dev enp1s8 table enp1s8
up ip rule add from 172.16.30.23/32 table enp1s8
up ip rule add to 172.16.30.23/32 table enp1s8
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.