OpenWrt Forum Archive

Topic: ARP / static routing question; am I doing this wrong?

The content of this topic has been archived on 31 Mar 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I'm having trouble doing a slightly odd static route configuration. I'm new to OpenWRT but not networking. I could use some help either setting this up or at least understanding what's going on with ARP.

My home LAN is set up on 192.168.0.*, with the OpenWRT box statically configured on 192.168.0.1 as the DHCP, NAT router, etc. It's a TP-Link Archer C7 running CC 15.05.

My WAN connection is via 10.33.1.1, gear from my ISP that gave the OpenWRT box the address 10.33.1.50 for the WAN port.

The weird part in my setup is the ISP gear is not wired to my OpenWRT box (too far away). Instead I have a pair of Ubiquiti Nanos forming a wireless ethernet bridge, transparently passing all layer 2 traffic. There is a wire running from the Ubiquiti node inside my house to the WAN port (eth0) on the OpenWRT box. And basically everything works fine; I can use the Internet no problem.

The problem is I want to also talk to the Ubiquiti gear directly. In addition to being an ethernet bridge, those boxes are configured on their own subnet, with addresses 192.168.1.110 and 192.168.1.111. Normally these IP addresses are invisible, but I'd like to be able to access them to get to the status and configuration pages for the router via their web server.

With my old Tomato-based router I was able to make this work easily by just setting up a static route for 192.168.1.* and telling it to use the WAN port to reach it. But when I try setting this up in OpenWRT it doesn't work; I get no response from the Ubiquiti gear to ping or HTTP. I do get a response to arping though, so something's getting through.

Looking a bit more closely with tcpdump, what's happening is when I try to ping from the OpenWRT box I see ARP requests from the Ubuiquti box that go unanswered. I have briefly gotten ping to work by stuffing an ARP entry into the Ubiquiti box via arping. But that only lasts a few seconds and seems hackish. I've also tried manually adding routes with various settings for the "src" parameter with no luck. And honestly I'm at the limits of my understanding of this stuff. I realize this question is convoluted, but hoping someone sees it and understands the problem!

Here's the unanswered ARP that to me is a symptom of the problem. I'm a bit confused why the Ubiquiti box is asking about 192.168.0.1 when the ping came in on 10.33.1.50

01:05:05.685693 IP 10.33.1.50 > 192.168.1.110: ICMP echo request, id 3239, seq 0, length 64
01:05:05.686895 ARP, Request who-has 192.168.0.1 tell 192.168.1.110, length 46

Here's the routing table I have on the OpenWRT router. This is what Luci set up, but I've tried some variants manually too.

default via 10.33.1.1 dev eth0  proto static  src 10.33.1.50
10.33.1.0/24 dev eth0  proto kernel  scope link  src 10.33.1.50
10.33.1.1 dev eth0  proto static  scope link  src 10.33.1.50
192.168.0.0/24 dev br-lan  proto kernel  scope link  src 192.168.0.1
192.168.1.0/24 dev eth0  proto static  scope link

Post a convoluted question, get no response :-) I finally figured out the problem was eth0 didn't know it was supposed to be 192.168.1.* as well. If I manually add an alias via "ip addr add 192.168.1.1/24 dev eth0" things work. I'm still a little in over my head with respect to bridging, routing, and aliases, but it's working for me.

Is there a right way to manually add an IP alias to an otherwise-DHCP configured network interface?

I've finished my configuration, sharing it here in case it helps anyone else. I ended up adding the alias permanently by following these docs and adding the following block to /etc/config/network. It seems to work fine, although the display in Luci is a bit confusing. (Both wan and ubiqnet show up as interfaces, having both addresses.)

config interface 'ubiqnet'
    option 'ifname' 'eth0'
    option 'proto' 'static'
    option 'ipaddr' '192.168.1.1'
    option 'netmask' '255.255.255.0'

The discussion might have continued from here.