3

I have a home router with an Internet connection. I also have a computer which is in a place where I cannot connect it directly to the router. Hopefully, I have two raspberry pis that I didn't know what to do with.

I'd like to achieve these results:

enter image description here

The IP of my computer cannot be changed as it is used by other devices on the router network.

So far, I've been able to do the following communications (IPs have been set with ifconfig):

Command Pi #1 Pi #2 Computer Any device on HomeRouter
ping 192.168.0.1 OK OK OK NOPE (Subnet is different)
ping 192.168.0.2 OK OK OK NOPE (Subnet is different)
ping 192.168.1.1 OK OK OK OK
ping 192.168.2.1 OK OK OK NOPE (Subnet is different)
ping 192.168.1.100 OK OK OK OK
ping 192.168.2.100 OK OK OK NOPE (Subnet is different)
ping 192.168.1.102 OK OK OK NOPE
curl 8.8.8.8 OK OK OK OK
curl google.com OK OK OK OK

The following command lines have been executed on both PI:

# Enable IP forwarding echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf echo 'net.ipv6.conf.all.forwarding=1' >> /etc/sysctl.conf sysctl -p /etc/sysctl.conf # Masquerade outgoing packets iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE # Add DNS echo "nameserver 8.8.8.8" | sudo tee -a /etc/resolv.conf
  • On PI #1, I've added the following route:
# Set static IP for both interfaces ifconfig eth0 192.168.1.100 netmask 255.255.255.0 ifconfig ppp0 192.168.0.1 netmask 255.255.255.0 # Add routes ip route add 192.168.2.0/24 via 192.168.0.2 dev ppp0 # Route packets to Pi #2
  • On PI #2, I've added the following route:
# Set static IP for both interfaces ifconfig eth0 192.168.2.1 netmask 255.255.255.0 ifconfig ppp0 192.168.0.2 netmask 255.255.255.0 # Add routes ip route add default via 192.168.0.1 ip route add 192.168.1.0/24 via 192.168.0.1 dev ppp0 # Route packets to Pi #1
  • On my computer:
# Set static IP ifconfig eth0 192.168.2.100 netmask 255.255.255.0 # Add routes ip route add default via 192.168.2.1 # Add DNS echo "nameserver 8.8.8.8" | sudo tee -a /etc/resolv.conf

I've tried to add a second IP on the eth0 interface of the first PI. The plan is to redirect all packets coming to 192.168.1.102 to 192.168.2.100.

# Add a new IP to PI #1's eth0 ip addr add 192.168.1.102 dev eth0 # Masquerade IP iptables -t nat -A PREROUTING -i eth0 -s 192.168.1.102 -j DNAT --to-destination 192.168.2.100 iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.2.100 -j SNAT --to-source 192.168.1.102

Would that work ?

Improve this question
5
  • Does the computer specifically need to have an 192.168.1.x address? Are there any "auto discovery" features that must work across this connection? There are two different options depending on your requirements. Commented Jun 16, 2023 at 17:02
  • Thanks for your answer. Actually, I do not know the IP of the computer. It can be set via DHCP or static (including subnetwork 192.168.1.0/24) Commented Jun 16, 2023 at 17:14
  • Without having spent too much thought on it (just looking at the IPs you've used) I'd say the main issue is that you're trying to have 192.168.1.0/24 on either side of 192.168.0.0/24 ... you shouldn't need iptables, just enable routing on both pi's and make static routes for each endpoint on all devices. Commented Jun 16, 2023 at 18:17
  • Do you have any clue on the ip routes I need to set ? Would it be easier if PI #2 eth0 was a DHCP server ? Commented Jun 16, 2023 at 18:32
  • I've updated my question with some routes but I don't master this kind of commands. Could you have a look please ? Commented Jun 16, 2023 at 19:26

1 Answer 1

Reset to default
1

If you want the same network number to exist on both ends, routing generally will not be enough.

In general, you need to remember that there is another layer of addressing that exists below IP. On Ethernet (and Wi-Fi), all packets are delivered to a specific MAC address – before your Pi can forward a packet it needs to receive that packet, and that'll only happen if the sender knows (either via ARP or via its routing table) that it needs to send the packet towards the Pi.

Your attempt to add /32 routes is a good start, but doing so on the Pi only helps if the packets get delivered to the Pi to begin with – currently, devices in the "left" 192.168.1.0/24 network do not know they need to send packets via the Pi#1's MAC.

In other words, your home router doesn't automatically know that 192.168.1.2 or 192.168.1.Y are behind another router – it's configured to assume that the entire /24 is "on-link", answering ARP replies.

This could be finished in two ways: either adding the same kind of /32 route via Pi#1 on "Home router" (as well as all other devices that would be connected to "Home router"), or configuring Pi#1 to perform proxy ARP, i.e. answering ARP queries on behalf of IPs that it doesn't directly have.

I would generally go for proxy ARP in this case; it can be set up via ip neigh add ... proxy on Linux (and/or the proxy_arp sysctl, which appears to be orthogonal to manually added proxy-neighbor entries), but the userspace parpd daemon is a bit easier to configure.

With proxy-ARP in place, when your home gateway (or some computer) tries to send packets to 192.168.1.Y, it will learn Pi#1's MAC address through ARP and will direct the packets there. You should do the same on the other end, providing proxy-ARP responses to PC Y on behalf of the rest of the /24.

Bridging would probably be a much better approach to the overall problem. You could set up a VXLAN or EoIP tunnel between both Pi's (basically Ethernet-over-IP), bridge the tunnel interface to the physical Ethernet interface, and you would literally have a single subnet stretching across from home router to computer Y, with everything (including ARP, IPv6, etc.) being forwarded at MAC layer.

Bridging could also be achieved without a tunnel if the Wi-Fi interfaces on the Pi support "4addr" mode; the AP is always bridgeable but the station needs to have 4addr mode activated to become bridgeable, and the AP must be configured to accept 4addr frames. In this case, the 192.168.0.0/24 subnet would be no longer needed; it would just be 192.168.1.0/24 all the way through.

Improve this answer
4
  • Thanks for your answer. I've edited my question using Bridging. Could you please take a look and let me know if I understand correctly the concept ? Commented Jun 17, 2023 at 12:39
  • 1
    You have the general idea right, but you forgot the actual bridging part, with using bridge or brctl to configure a L2 bridge between eth0 and eoip0. But as far as I know Linux doesn't have a literal eoip tunnel type (sadly), so you would need to use VXLAN which is point-to-multipoint but serves nearly the same purpose. (Mikrotik RouterOS has GRE-style EoIP though.) Commented Jun 17, 2023 at 12:59
  • I've updated my code to use VXLAN. Could you have a quick look ? Commented Jun 17, 2023 at 13:16
  • I've updated my question with NAT rules to redirect an IP to another. Could you have a quick look please ? Commented Jun 22, 2023 at 14:07

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.