Join Log in
Score:1
Jonathan avatar Ubuntu

Unable to establish network route

cn flag
Jonathan

I am struggling to establish a network route from my laptop to another device. I will admit that my networking background is lacking, so sorry for the ignorance. I have the following setup:

[Device-A] <--WiFi--> [router] <--WiFi--> [Device-B] <--Ethernet--> [Device-C]

I have the following IP addresses (which were configured automatically):

Device-A:

  • wifi: 192.168.0.155

Device-B:

  • wifi: 192.168.0.121
  • ethernet: 10.42.0.1

Device-C:

  • ethernet: 10.42.0.134

All devices are using Ubuntu 20.04. I configured the wired connection between Device-B and Device-C on Device-B using network manager GUI with IPv4 Method set to "Share to other computers". All other settings were left at defaults. On Device-A, I tried to set a route to Device-C using:

sudo ip route add 10.42.0.0/24 via 192.168.0.121 dev wlo1

Device-C is able to ping Device-A and Device-A can ping Device-B at both 192.168.0.121 and 10.42.0.1. However, when I try to ping Device-C from Device-A I get:

$ ping 10.42.0.134
PING 10.42.0.134 (10.42.0.134) 56(84) bytes of data.
From 192.168.0.121 icmp_seq=1 Destination Port Unreachable

How can a configure the devices so that Device-A is able to talk to Device-C? This seems like something that should be fairly simple but I have not been able to figure it out.

Update

Forwarding is enabled on B

$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Here are my iptables rulesets on B:

$ sudo iptables -L -n -v
Chain INPUT (policy ACCEPT 20319 packets, 21M bytes)
 pkts bytes target     prot opt in     out     source               destination         
    6  2236 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:67
   12   863 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  193 33179 ACCEPT     all  --  *      eth0    0.0.0.0/0            10.42.0.0/24         state RELATED,ESTABLISHED
  201 19734 ACCEPT     all  --  eth0   *       10.42.0.0/24         0.0.0.0/0           
    0     0 ACCEPT     all  --  eth0   eth0    0.0.0.0/0            0.0.0.0/0           
    9   756 REJECT     all  --  *      eth0    0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT 18275 packets, 2577K bytes)
 pkts bytes target     prot opt in     out     source               destination         

$ sudo iptables -L -n -v -t nat
Chain PREROUTING (policy ACCEPT 577 packets, 172K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 59 packets, 4904 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 476 packets, 67069 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 468 packets, 65733 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  178 14264 MASQUERADE  all  --  *      *       10.42.0.0/24        !10.42.0.0/24

I have not configured any firewall rules on B.

51
1 + 3
ru flag
Thomas Ward
We need to see your network configurations. If B is acting as a router then chances are B is not configured correctly; you need more than just routing rules to make sure stuff properly forwards between network interfaces.
1
Reply
Jonathan avatar
cn flag
Jonathan
@ThomasWard what additional information do you need? Would the output of `ifconfig` from B be helpful? Running `sysctl net.ipv4.ip_forward` returns 1.
0
Reply
ru flag
Thomas Ward
Your current `iptables` rulesets for NAT, etc. on B are important here. `sudo iptables -L -n -v -t nat` and `sudo iptables -L -n -v` output. Firewall rules you *have* configured on any relevant devices. Your route rule on C is also *wrong* because its gateway is going to be the IP address of that subnet on B for gateway, not direct-to-A.
1
Reply
Score:0
Jonathan avatar Ubuntu
cn flag
Jonathan

The problem was the iptables ruleset on Device-B (thanks to help from Thomas in the comments).

As shown in the question in the output of sudo iptables -L -n -v, you can see that packets going through B are getting rejected instead of being forwarded to eth0 (shown as the fourth entry below "Chain FORWARD" in the question). I was able to list all forwarding rules using the iptables -S command:

$ sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 53 -j ACCEPT
-A FORWARD -d 10.42.0.0/24 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.42.0.0/24 -i eth0 -j ACCEPT
-A FORWARD -i eth0 -o eth0 -j ACCEPT
-A FORWARD -o eth0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i eth0 -j REJECT --reject-with icmp-port-unreachable

From the output, the last two rules are what is creating the problem. I removed these using the following:

sudo iptables -D FORWARD -o eth0 -j REJECT
sudo iptables -D FORWARD -i eth0 -j REJECT

I am now able to ping/ssh into Device-C from Device-A, and vice versa.

+ 0
ธงชาติไทย
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.