Join Log in
Score:1
sbx avatar Server

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

co flag
sbx

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:

enter image description here

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

1

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:

enter image description here

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

599
1 + 18
Torin avatar
in flag
Torin
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
0
Reply
sbx avatar
co flag
sbx
@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
0
Reply
Torin avatar
in flag
Torin
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
0
Reply
sbx avatar
co flag
sbx
@Torin got it, changed to: `-A POSTROUTING -s 10.8.0.0/24 -o wlan1 -j MASQUERADE` , no effect on pinging Android yet
0
Reply
jabbson avatar
sb flag
jabbson
`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?
0
Reply
Torin avatar
in flag
Torin
Sorry on second thought my previous comment wasn't actually helpful since I got mixed up with networks. I would have `-A POSTROUTING -o wlan1 -j MASQUERADE` (i.e. without the source), although this won't fix the issue.
0
Reply
sbx avatar
co flag
sbx
@jabbson `tcpdump` output fixed, I tried also pinging wlan0 connected ESP - also unreachable, so it is not just Android. `iptables` rules are affected by OpenVPN server - it simply adds them there. Final `ACCEPT` override all before - I removed that, but it didn't affect reachability.
0
Reply
sbx avatar
co flag
sbx
@Torin thank you anyway.
0
Reply
jabbson avatar
sb flag
jabbson
Could you extend the tcpdump capture to `-i any -n 'icmp or arp'`? Also could you run `arp -a` on the debian host while/right after pinging?
0
Reply
sbx avatar
co flag
sbx
@jabbson outputs of both added to 'Edits as requested in comments:'
0
Reply
jabbson avatar
sb flag
jabbson
with all of this info it feels like the ip_forwarding is not working, can you check that `sysctl -a | grep '\.forw'` again? Or `sysctl net.inet.ip.forwarding` specifically.
0
Reply
sbx avatar
co flag
sbx
Thank you @jabbson. I have added what you suggested to 'More forwarding logs:'
0
Reply
Martin avatar
kz flag
Martin
I stumbled over the line `# Warning: iptables-legacy tables present, use iptables-legacy-save to see them`. Are there any rules present, did you check?
0
Reply
sbx avatar
co flag
sbx
@Martin, it's is empty, log added `iptables-legacy-save`. Thank you for noticing.
0
Reply
jabbson avatar
sb flag
jabbson
out of curiosity (and obviously desperation), could you show us your `ip rule list` as well?
0
Reply
sbx avatar
co flag
sbx
sure @jabbson, `ip rule list` added - I don't have any experience with rules, but I didn't change anything, if I can provide more info, I will do that... I am afraid I am facing some serious and hidden bug somewhere.. despite that I am keen to investigate more as this is really strange
0
Reply
jabbson avatar
sb flag
jabbson
nope, this looks very default too
0
Reply
Martin avatar
kz flag
Martin
One further idea. You probably are running a dhcp server for both wlan0 and eth0 interfaces on your debian server. Maybe check this configuration for anything faulty?
0
Reply
Score:0
A. Trevelyan avatar Server
id flag
A. Trevelyan

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.

+ 4
sbx avatar
co flag
sbx
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...
0
Reply
sbx avatar
co flag
sbx
`10.42.1.0` and `10.42.1.1` are dropping you say...
0
Reply
A. Trevelyan avatar
id flag
A. Trevelyan
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.
0
Reply
sbx avatar
co flag
sbx
ufw is disabled whole time.. thank you for the effort A. Trevelyan.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.