Debian Server - clients can't ping between interfaces/subnets

Question

I can't ping clients between interfaces/subnets e.g. pinging from Mac (10.42.0.82), which is connected to eth0 to the Android (10.42.1.150) which is connected to wlan0.

Note: I can access internet from all devices.

Note Edit #1: Android is connected and awake, I can ping device if I am connected via wlan0 on Mac - this not solving my problem.

How to forward connection between these devices?

There is quick drawing of my network:

Debian Server with 3 interfaces:

wlan1 (192.168.1.25) - internet access
eth0 (10.42.0.1) - clients 10.42.0.0/24
wlan0 (10.42.1.0) - clients 10.42.1.0/24

besides that, there is OpenVPN running on Debian Server so (tun0 is present as well)*

Outputs from Mac:

ping 192.168.150

PING 10.42.1.150 (10.42.1.150): 56 data bytes
92 bytes from machine (10.42.0.1): Destination Port Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 fc85   0 0000  3f  01 68e8 10.42.0.82  10.42.1.150 

Request timeout for icmp_seq 0
92 bytes from machine (10.42.0.1): Destination Port Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 6410   0 0000  3f  01 015e 10.42.0.82  10.42.1.150

Outputs from Debian:

Dumping packets while pinging Android from Mac:

tcpdump -i eth0 -c 10 -n icmp

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:57:03.887954 IP 10.42.0.82 > 10.42.1.150: ICMP echo request, id 2813, seq 0, length 64
15:57:03.888133 IP 10.42.0.1 > 10.42.0.82: ICMP 10.42.1.150 protocol 1 port 16598 unreachable, length 92
15:57:04.893099 IP 10.42.0.82 > 10.42.1.150: ICMP echo request, id 2813, seq 1, length 64
15:57:04.893431 IP 10.42.0.1 > 10.42.0.82: ICMP 10.42.1.150 protocol 1 port 11180 unreachable, length 92

tcpdump -i wlan0 -c 10 -n icmp

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

...silence...

TRACEROUTE

traceroute 10.42.1.150 - eth0 gateway response

traceroute to 10.42.1.150 (10.42.1.150), 64 hops max, 52 byte packets
 1  machine (10.42.0.1)  0.988 ms  0.661 ms  0.757 ms
 2  machine (10.42.0.1)  0.803 ms  0.865 ms  0.712 ms

Edits as requested in comments: sudo tcpdump -nni eth0 -i any -n 'icmp or arp'

16:24:22.960833 eth0  In  IP 10.42.0.82 > 10.42.1.150: ICMP echo request, id 51712, seq 0, length 64
16:24:22.961074 eth0  Out IP 10.42.0.1 > 10.42.0.82: ICMP 10.42.1.150 protocol 1 port 8729 unreachable, length 92
16:24:23.680270 wlan0 In  ARP, Request who-has 10.42.0.1 tell 10.42.1.150, length 28
16:24:23.680339 wlan0 Out ARP, Reply 10.42.0.1 is-at 74:e5:43:29:9b:4e, length 28
16:24:23.961291 eth0  In  IP 10.42.0.82 > 10.42.1.150: ICMP echo request, id 51712, seq 1, length 64
16:24:23.961542 eth0  Out IP 10.42.0.1 > 10.42.0.82: ICMP 10.42.1.150 protocol 1 port 8423 unreachable, length 92
16:24:24.963007 eth0  In  IP 10.42.0.82 > 10.42.1.150: ICMP echo request, id 51712, seq 2, length 64
16:24:24.963261 eth0  Out IP 10.42.0.1 > 10.42.0.82: ICMP 10.42.1.150 protocol 1 port 6743 unreachable, length 92

arp -a

mac.lan (10.42.0.82) at 00:e0:4c:68:09:6c [ether] on eth0
workstation.lan (10.42.0.212) at 4c:cc:6a:8e:cf:70 [ether] on eth0
a2.lan (10.42.1.150) at 8e:0f:d2:95:50:41 [ether] on wlan0
? (192.168.1.1) at 6c:5a:b0:0c:ff:f4 [ether] on wlan1
? (192.168.1.90) at <incomplete> on wlan1
espd.lan (10.42.1.190) at 5c:cf:7f:68:00:92 [ether] on wlan0
? (192.168.1.158) at e0:dc:ff:08:e4:cc [ether] on wlan1
? (192.168.1.155) at 58:fb:84:3f:77:cb [ether] on wlan1
? (192.168.1.53) at d0:3c:1f:37:85:57 [ether] on wlan1

netstat -nr

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 wlan1
10.8.0.0        0.0.0.0         255.255.255.0   U         0 0          0 tun0
10.42.0.0       0.0.0.0         255.255.255.0   U         0 0          0 eth0
10.42.1.0       0.0.0.0         255.255.255.0   U         0 0          0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 wlan1

ip route

default via 192.168.1.1 dev wlan1 proto dhcp src 192.168.1.25 metric 601 
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1 
10.42.0.0/24 dev eth0 proto kernel scope link src 10.42.0.1 metric 100 
10.42.1.0/24 dev wlan0 proto kernel scope link src 10.42.1.1 metric 600 
192.168.1.0/24 dev wlan1 proto kernel scope link src 192.168.1.25 metric 601

iptables-save

# Generated by iptables-save v1.8.8 (nf_tables) on Wed Nov  9 12:38:09 2022
*filter
:INPUT ACCEPT [6046:607118]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [10078:1146969]
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -i wlan1 -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -i wlan1 -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -j ACCEPT
-A FORWARD -i tun0 -o wlan1 -j ACCEPT
-A FORWARD -i wlan1 -o tun0 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -j ACCEPT
-A FORWARD -i tun0 -o wlan1 -j ACCEPT
-A FORWARD -i wlan1 -o tun0 -j ACCEPT
-A FORWARD -j ACCEPT
COMMIT
# Completed on Wed Nov  9 12:38:09 2022
# Generated by iptables-save v1.8.8 (nf_tables) on Wed Nov  9 12:38:09 2022
*nat
:PREROUTING ACCEPT [3107:427832]
:INPUT ACCEPT [826:76600]
:OUTPUT ACCEPT [1808:145801]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.8.0.0/24 -o wlan1 -j MASQUERADE
-A POSTROUTING -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 192.168.1.25
COMMIT
# Completed on Wed Nov  9 12:38:09 2022
# Warning: iptables-legacy tables present, use iptables-legacy-save to see them

iptables-legacy-save - legacy iptables are empty

# Generated by iptables-save v1.8.8 on Fri Nov 11 16:59:47 2022
*nat
:PREROUTING ACCEPT [321648:59396444]
:INPUT ACCEPT [130230:10386836]
:OUTPUT ACCEPT [299654:30414342]
:POSTROUTING ACCEPT [228403:20881622]
COMMIT
# Completed on Fri Nov 11 16:59:47 2022

ip rule list

0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

cat /proc/sys/net/ipv4/ip_forward

More forwarding logs:

sudo sysctl -a | grep '\.forw'

net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.eth0.forwarding = 1
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.tun0.forwarding = 1
net.ipv4.conf.wlan0.forwarding = 1
net.ipv4.conf.wlan1.forwarding = 1
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.eth0.forwarding = 1
net.ipv6.conf.lo.forwarding = 1
net.ipv6.conf.tun0.forwarding = 1
net.ipv6.conf.wlan0.forwarding = 1
net.ipv6.conf.wlan1.forwarding = 1

&

sysctl net.inet.ip.forwarding
sysctl: cannot stat /proc/sys/net/inet/ip/forwarding: No such file or directory

ifconfig

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.42.0.1  netmask 255.255.255.0  broadcast 10.42.0.255
        inet6 fe80::4c6d:de50:a3d1:cbe  prefixlen 64  scopeid 0x20<link>
        ether 30:85:a9:11:cb:df  txqueuelen 1000  (Ethernet)
        RX packets 307275  bytes 47966154 (45.7 MiB)
        RX errors 0  dropped 9  overruns 0  frame 0
        TX packets 510676  bytes 566627587 (540.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 1  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 35262  bytes 7210507 (6.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 35262  bytes 7210507 (6.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.8.0.1  netmask 255.255.255.0  destination 10.8.0.1
        inet6 fe80::a28:40b6:7db3:b6e1  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 4323  bytes 546964 (534.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3912  bytes 1024431 (1000.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.42.1.1  netmask 255.255.255.0  broadcast 10.42.1.255
        inet6 fe80::59ba:e291:f2f9:628b  prefixlen 64  scopeid 0x20<link>
        ether 74:e5:43:29:9b:4e  txqueuelen 1000  (Ethernet)
        RX packets 40418  bytes 7657042 (7.3 MiB)
        RX errors 0  dropped 16  overruns 0  frame 0
        TX packets 63120  bytes 25176738 (24.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.25  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::501b:a922:3efd:94ba  prefixlen 64  scopeid 0x20<link>
        ether d0:37:45:f5:f2:ae  txqueuelen 1000  (Ethernet)
        RX packets 608317  bytes 646981557 (617.0 MiB)
        RX errors 0  dropped 223  overruns 0  frame 0
        TX packets 374790  bytes 72410599 (69.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ping from Android:

Thank you for any advice which will push me to desired resolution of this!

Is the pinging happening at the same time as the phone being actively awake (i.e. not in sleep)? Also, the sole -A POSTROUTING -j MASQUERADE probably isn't what you want — Torin, Nov 9, 2022 at 14:09
@Torin yes sure, it works if I connect Mac on wifi network and try to ping Android, thanks for reminding me that MASQUERADE it was added just for test — sbx, Nov 9, 2022 at 14:12
The -A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 192.168.1.25 is also looking a bit suspect, since this will affect 10.8.0.0/24 -> 10.8.1.0/24 traffic. You already have -A POSTROUTING -s 10.8.0.0/24 -o wlan1 -j MASQUERADE so I suggest removing the second and third masquerade/snats — Torin, Nov 9, 2022 at 14:13
@Torin got it, changed to: -A POSTROUTING -s 10.8.0.0/24 -o wlan1 -j MASQUERADE , no effect on pinging Android yet — sbx, Nov 9, 2022 at 14:17
Outputs from Mac says ping 192.168.150 (probably missing one octet to begin with). Below that the output show that the ping is to 10.42.1.150. Which one is it? In the output of tcpdump we see that the packets are destined to 10.42.1.190, which isn't the android host. Any idea why? The FORWARD chain shows a lot of ACCEPT jumps, while there is also an explicit ACCEPT at the bottom and the default is also ACCEPT, was this done just for tests? — jabbson, Nov 9, 2022 at 14:49

A. Trevelyan · Accepted Answer · 2022-11-11 19:36:26Z

The fact you're getting this response:

PING 10.42.1.150 (10.42.1.150): 56 data bytes
92 bytes from machine (10.42.0.1): Destination Port Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 fc85   0 0000  3f  01 68e8 10.42.0.82  10.42.1.150

means that 10.42.0.1 is dropping (and notifying) that it cannot deliver the packet.

There's a lot of extra details here that aren't necessarily relevant if you're just trying to figure out the forwarding between eth0 & wlan0, but I guess its fair since you've been updating based on comments and just trying to get to it figured out.

Everything looks more or less fine up to the iptables rules to me, these rules:

-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -j ACCEPT
-A FORWARD -i tun0 -o wlan1 -j ACCEPT
-A FORWARD -i wlan1 -o tun0 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -j ACCEPT
-A FORWARD -i tun0 -o wlan1 -j ACCEPT
-A FORWARD -i wlan1 -o tun0 -j ACCEPT

seem to just be 4 rules with 4 duplicates - you should probably remove the dupes to make it less confusing.

The part that's weirdest about this though is you have this: -A FORWARD -j ACCEPT, which logically I think should mean just accept all traffic to forward, which should be what you want, but apparently that's not happening.

I think a rule like this is not typically used though, could you try to replace that with:

-A FORWARD -i wlan0 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o wlan0 -j ACCEPT

and see what happens?

Also, what do you see if you try the reverse ping? ie: 10.42.1.150 --> 10.42.0.82 You can use an app like PingTools, Ping, or Ping & Net to try it.

Thank you A. Trevelyan, I tryed to ping from Android, screenshot added at the bottom (cant make it smaller somehow). Reponse is the same. Yes, it is same for me, -A FORWARD -j ACCEPT should secure forwarding in generel - it is not doing that. BUT, I changed iptables as you suggested - dups removed, more accurate forwarding between wlan0 and eth0 added - no success... — sbx, Nov 11, 2022 at 22:51
This is a weird one. I'm honestly not sure what the root cause could be at this point. Do u have ufw installed? Maybe try disabling it if u do: sudo ufw disable and see, other than that I'm not sure what else it could be. — A. Trevelyan, Nov 12, 2022 at 0:18
ufw is disabled whole time.. thank you for the effort A. Trevelyan. — sbx, Nov 12, 2022 at 0:47

Stack Exchange Network

Debian Server - clients can't ping between interfaces/subnets

1 Answer 1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged
linux
debian
routing
networkmanager
routes
.

Linked

Hot Network Questions

Debian Server - clients can't ping between interfaces/subnets

1 Answer 1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged linuxdebianroutingnetworkmanagerroutes.

Linked

Related

Hot Network Questions

Not the answer you're looking for? Browse other questions tagged
linux
debian
routing
networkmanager
routes
.