Destination Port Unreachable on local network

Question

I've got three computers in my local network: A, B, C

• A has an ethernet connection to the router
• B has a wireless connection to the router and shares his internet access with C
• C is connected to B through an ethernet cable

All three have an internet access.

• From B, I can ping A and C
• From C, I can ping A and B
• But from A I can only ping B, C being of reach : Destination Port Unreachable

Here is 'ip route show' on A

default via 192.168.1.1 dev enp2s0 proto dhcp src 192.168.1.85 metric 1024 
192.168.1.0/16 dev enp2s0 proto kernel scope link src 192.168.1.85 metric 1024 
192.168.1.1 dev enp2s0 proto dhcp scope link src 192.168.1.85 metric 1024

Here is 'ip route show' on B

default via 192.168.1.1 dev wlx347de4402df9 proto dhcp metric 600 
10.42.0.0/24 dev enp5s0 proto kernel scope link src 10.42.0.1 metric 100 
169.254.0.0/16 dev enp5s0 scope link metric 1000 
192.168.1.0/24 dev wlx347de4402df9 proto kernel scope link src 192.168.1.180 metric 600 

And here is 'ip route show' on C

default via 10.42.0.1 devenp2s0 proto dhcp metric 100 
10.42.0.0/24 dev enp2s0 proto kernel scope link src 10.42.0.169 metric 100 
169.254.0.0/16 dev enp2s0 scope link metric 1000  

So now in terms of IP addresses:

From B I can:

• ping/ssh 192.168.1.85 (A)
• ping/ssh 10.42.0.169 (C)

From C I can:

• ping/ssh 192.168.1.85 (A)
• ping/ssh 192.168.1.180 (B)
• ping/ssh 10.42.0.1 (B as well)

From A I can:

• ping/ssh 192.168.1.180 (B)

What I can't do is ping/ssh 10.42.0.169 and 10.42.0.1

After I added a route on A with 'ip route 10.42.0.0/24 via 192.168.1.180' I can now ping B as 10.42.0.1 but still cannot access C. 'ping 10.42.0.169' gives me:

From 192.168.1.180 icmp_seq=1 Destination Port Unreachable
From 192.168.1.180 icmp_seq=2 Destination Port Unreachable
From 192.168.1.180 icmp_seq=3 Destination Port Unreachable

How can I make C reachable by A?

On B 'iptables-save' outputs nothing and here is the output of 'nft list ruleset'

table ip nm-shared-enp5s0 {
    chain nat_postrouting {
        type nat hook postrouting priority srcnat; policy accept;
        ip saddr 10.42.0.0/24 ip daddr != 10.42.0.0/24 masquerade
    }

    chain filter_forward {
        type filter hook forward priority filter; policy accept;
        ip daddr 10.42.0.0/24 oifname "enp5s0" ct state { established, related } accept
        ip saddr 10.42.0.0/24 iifname "enp5s0" accept
        iifname "enp5s0" oifname "enp5s0" accept
        iifname "enp5s0" reject
        oifname "enp5s0" reject
    }
}

On C both 'nft list ruleset' and 'iptables-save' output nothing.

Answer 1

Technically what you need in addition would be just:

ip route add 10.42.0.0/24 via 192.168.1.180

on A, assuming the firewall (iptables and/or nftables) on B (and the firewall on C) does not by any rules forbid traffics for C that are initiated by A.

Since B appears to be a Linux host, that means the NAT on it is stateful, which means it won't be applied to the replying traffics from C and hence won't be a problem.

(And since B is already working as a "gateway" for C, it means that the net.ipv4.ip_forward sysctl has already been set to 1.)

---

In the hook forward chain in your nftables ruleset, there is the rule:

ip daddr 10.42.0.0/24 oifname "enp5s0" ct state { established, related } accept

which matches and allows only "replying traffics" (well, ct state established is a bit complicated and is not the focus here, so) for 10.42.0.0/24 to be forwarded via enp5s0.

While the chain has policy accept, it also has the rule:

oifname "enp5s0" reject

which matches and rejects the "original traffics" (i.e. ct state new; communication-initiating) that targets 10.42.0.0/24, because they would not be matched by any earlier rule and would be forwarded via enp5s0 as per the route table. (Not that the rule will match only those traffics though.)

Note that the following rule would not match the traffics because iifname "enp5s0" would not be the case of them (I mean, assuming they are from A):

iifname "enp5s0" oifname "enp5s0" accept

TL;DR. You need to remove ct state { established, related } from the first rule I quoted above. (While there's also the ct state invalid, but since you did not filter such traffics in any rule, so.)