0

I've got the following network setup

[ISP Router] <---> [Raspbian] <---> [Debian 10 Workstation]

Here's some info from my Raspbian "router"

iptables has been flushed with iptables -F, the default policy for all chains is ACCEPT

ip a reports that on eth0 and eth1 the ip addresses have been set to the values I expect to see. (eth0 is 192.168.1.201, set using a reserved address by the ISP Router DHCP server. eth1 is set statically using /etc/dhcpcd.conf to 192.168.2.254.)

Here is the routing table info:

default via 192.168.1.254 dev eth0 proto dhcp src 192.168.1.201 metric 202
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.201 metric 202
192.168.2.0/24 dev eth1 proto dhcp scope link src 192.168.2.254 metric 203

I can't see any obvious errors with that, and I believe that with the iptables clear, and default policy of ACCEPT, this should be forwarding all packets destined for any addresses in the routing table. cat /proc/sys/net/ipv4/ip_forward returns 1.

Here's the info reported by my workstation.

ip route
default via 127.0.0.1 dev enx00500b668976b proto dhcp metric 100
default via 127.0.0.1 dev enx00500b668976b proto dhcp metric 101
10.0.0.0/8 dev enp7s0 proto kernel scope link sec 10.0.0.1
127.0.0.1 dev enx00500b668976b proto dhcp scope link metric 100
192.168.2.0/24 dev enx00500b668976b proto kernel scope link src 192.168.2.10

This looks a bit weird to me.

I can ping 192.168.1.254 from the Rasbian system, but I cannot ping this address from my workstation, suggesting there is a problem with the link between these two devices.

What can I do to diagnose this problem?

Are there any obvious mistakes with the setup I have as indicated by the information above?

5
  • 1
    Is the ISP issued router or the hosts on the network configured to route the subnet 192.168.2.0/24 to the pi? – Torin May 23 '20 at 13:15
  • @Torin I'm sorry I don't think I fully understand the question, or perhaps the relevance of it? Can you elaborate? – user3728501 May 23 '20 at 13:20
  • When the ISP router receives a packet destined for 192.168.2.0/24, it needs to know where to send it. You need to set up a static route on the ISP router so that the subnet 192.168.2.0/24 is sent to the raspberry pi. – Torin May 23 '20 at 13:32
  • An alternative approach would be to translate the source addresses of packets leaving the pi subnet (SNAT). This wouldn't require modifying the ISP router configuration but does mean that you cannot address the devices on the subnet from the larget network. On the pi, something along the lines of iptables -t nat -A POSTROUTING -i eth1 -o eth0 -s 192.168.2.0/24 -j MASQUERADE may work – Torin May 23 '20 at 13:38
  • @Torin Yes of course! That's why I was using NAT before. That's obviously no longer working because I flushed my tables. – user3728501 May 23 '20 at 13:44
0

Partial Answer (maybe)

I did some research on how to diagnose issues.

I installed tcpdump on the Raspberry Pi, and monitored eth1. I saw ARP requests asking for "who has localhost".

I edited /etc/dhcp/dhcpd.conf and found the line option routers localhost;. I'm guessing this isn't a valid option, although it wasn't reported by journalctl -xe. (Or at least I don't think it was, I didn't notice any errors at boot time.)

I changed this to option routers 192.168.2.254. This "seems" wrong to me. I would have thought it should be localhost or 127.0.0.1... Because the Pi is both the DHCP server for the network 192.168.2.0 and the router for this network.

Rebooted, cleared iptables again, and now I can ping across the router (Pi).

Further Info

Ok, I now can't ping, but I could a moment ago...

On my workstation I now see this as my routing table

10.0.0.0/8 dev enp7s0 proto kernel scope link src 10.0.0.1
127.0.0.1 dev enx0050b668976b proto dhcp scope link metric 100
192.168.2.0/24 enx0050b668976b proto kernel scope link src 192.168.2.10 metric 100

That looks more like what I would expect to see.

After restarting I just have

10.0.0.0/8 dev enp7s0 proto kernel scope link src 10.0.0.1
192.168.2.0/24 enx0050b668976b proto kernel scope link src 192.168.2.10 metric 100

It is now working, I'm not 100 % sure why - most likely an iptables issue caused by flushing which cleared NAT?

Restarted both devices.

Here's the output of iptables --list -v

sudo iptables --list -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  185 21142 ACCEPT     all  --  lo     any     anywhere             anywhere            
  124 11380 ACCEPT     tcp  --  eth1   any     anywhere             anywhere             tcp dpt:ssh
  107 16316 ACCEPT     all  --  any    any     anywhere             anywhere             state RELATED,ESTABLISHED
   34  2936 DROP       all  --  eth0   any     anywhere             anywhere            

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

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

Routing table:

default via 192.168.1.254 dev eth0 proto dhcp src 192.168.1.201 metric 202 
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.201 metric 202 
192.168.2.0/24 dev eth1 proto dhcp scope link src 192.168.2.254 metric 203

Workstation routing table:

default via 192.168.2.254 dev enx0050b668976b proto dhcp metric 100 
10.0.0.0/8 dev enp7s0 proto kernel scope link src 10.0.0.1 
192.168.2.0/24 dev enx0050b668976b proto kernel scope link src 192.168.2.10 metric 100

It seems that default came back. I'm really not sure why this has happened, other than an incorrect configuration somewhere.

Here's my subnet definition in `/etc/dhcp/dhcpd.conf

subnet 192.168.2.0 netmask 255.255.255.0 {
  range 192.168.2.10 192.168.2.120;
  option routers 192.168.2.254;
  option broadcast-address 192.168.2.255;
}

Again, a bit weird that 192.168.2.254 is used here rather than something like 127.0.0.1, but I guess if it works?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.