Routing trouble?

Hello,

I'm trying to setup a new router and I am experiencing something strange there.

Here's the situation:

  • router A is my router, running fine on latest OpenWRT 21
  • there are two vlans on A:
    • 1.1.1.0/24: home network
    • 2.2.2.0/24: dmz
  • my working pc is on 1.1.1.2
  • a Raspberry Pi is on 2.2.2.2

Everything works as it is supposed to: both machines can reach the internet, my home network can reach the dmz, but not vice versa.

Enter router B, which has been freshly flashed with latest OpenWRT 22 and is to be setup for a similar scenario. To make things a bit easier, I want to make B part of my dmz, so I can open A and B simultaneously inside browser tabs and do some copy&paste. Sadly, A and B contain some different hardware, so I can not simply copy the hole configuration. I tried that and B wouldn't start at all.

I booted B in recovery mode and changed it's ip from 192.168.1.1 to 2.2.2.20/24 and then I rebooted and connected B to the dmz port on A.

So, now you would expect that B is just another machine inside the dmz and that it should behave like any other machine inside that network. But here comes the fishy part: my pc can not reach B, no matter what I try, while the Raspberry still can be reached normally by my pc.

But: I can ssh into A and then ssh into B from there.

At the same time I can ssh into the Raspberry from my pc just like always!

I do not understand what is going on there. I checked every firewall rule and there are no manual routing tables. I even deactivated the firewall completely once, but still it does not work. I also tried by changing B to completely mimic the Raspberry by setting its ip to the Raspberry's ip, but still B can not be reached from my pc. But still it can be reached using cascaded ssh.

Is there any secret feature in OpenWRT that keeps it from being used the way I am trying to? Can anyone make any sense of my wring and/or this situation?

Any help is highly appreciated! Just let me know which information is need in particular to solve this riddle, but please be a bit gentle to me, because I am just a novice among the circle of router wizards. :wink:

Thank you in advance!

Quick question

Why are you using public ip ranges for your private vlans?

1 Like
  • Am I right to assume that you connected a LAN port of router B to a DMZ port on router A?
  • How are the VLANs implemented (ports tagged, untagged)? Does it involve switches?
  • How is the Raspberry PI connected? Do you have dedicated DMZ ports?

Thanks for trying to help me! I will try to answer your questions the best I can:

  1. Yes: lan1 on router B is connected to the dmz port on router A.

  2. The vlans are implemented as told in the OpenWRT wiki: tagged on the cpu side, and untagged on the lan ports. But it doesn't make any difference if I tag them on the lan ports or not. The second part of your questions I don't quite understand. If you're asking whether there's an additional switch in use between router A and its client(s): no, there isn't. Every machine is connected directly to one of its lan ports. No further switch or hub involved.

  3. The Raspberry is plugged into router A on lan2, which is providing the dmz by setting the internal switch to that network. I tried to connect router B to this lan2 port, and I tried setting the switch to provide that network on port 3 as well. In both cases I can connect to router B by ssh into router A and then ssh into router B, but neither way I can ssh into router B from my pc.

As fas as I know, this setup SHOULD provide access to router B from my pc without any trouble. After all, my pc can access the Raspberry without any trouble whatsoever. This is absolutely strange behaviour, I can't find a rational explanation to it. :frowning:

Ok, summary:

  • router A DMZ <-> router B LAN
  • Your DMZ zone has a DHCP running and is giving out IPs in the 2.2.2.0/24 range
  • You set router B's LAN to 2.2.2.0/24 and if you didn't change anything it will also have a DHCP server running and giving out IPs in the 2.2.2.0/24 range

That won't work ... two DHCP servers and as a result router B won't receive an IP from the DMZ for it's LAN.

If I'd do something like it I connect router B's WAN port to the DMZ port and enable SSH and WebGUI access through the WAN port. ( router A DMZ <-> router B WAN). Per default on the WAN port runs a DHCP client and that will receive an IP from the DMZ.
But you would have to change the router B LAN to something different than 2.2.2.0/24.

Patient0: that sounds reasonable, but deactivating both dhcp doesn't make it work either.

Besides: when router B is running in recovery mode, it does not start its dhcp server. So, when I set port 2 on router A to 192.168.1.2 and try to connect from my pc, there is no collision of two dhcp services.

And if the problem was caused be colliding dhcp services, shouldn't it also keep router a from ssh'ing into router B?

For the second part of your anwer: that sounds promising! I'd like to try that. Could you tell my, how to configure router B to run WebGUI on wan port via command line?

The first example of "Firewall Examples" shows how to enable SSH access to WAN, Opening ports on the OpenWrt router.

Don't disable both DHCP, you will need one of course. In my view it can't work, even accessing router B from router A shouldn't work. Because both routers should have IP 2.2.2.1 for the LAN the way you set it. And therefore if you think you ssh from router A to router B you should in reality actually SSH into itself, router A.

What are the LAN IPs of the routers?

Thanks again, especially for the link! I will see to it at the weekend.

I think there's some misunderstanding:

One of router A's ports is permanently set to 2.2.2.1, and on that port, my dmz, dhcp is deactivated. Every machine in this network uses a static ip. I manually set router B to static 2.2.2.20 while in recovery mode. So, when I connect lan1 of router B to the dmz port of router A, it should behave just like any other machine that is part of the dmz.

But this doesn't work. My pc, being on the other vlan on router A, can reach every other machine I put into the dmz, but router B stays unreachable, while at the same time, I can reach router B from inside router A. This is very mysterious to me, and it's a pity that Scully and Mulder retired years ago.

I even tried giving router B the same ip as the Rasperry, which I unplugged, of course. I thought maybe a strange firewall rule slipped my attention, and by mimicking an already known machine, I could bypass this misfortune. But that didn't work either.

Long story short: in all my experiences I made sure that there never were two machines using the same ip.

I missed that you set router B to 2.2.2.20/24 (read it as 2.2.2.0/20), Sorry.

Then it does make more sense, asynchronous routing is maybe then the issue.

  • router A DMZ is on the same subnet as router B, no routing involved and that's why it works when you SSH from router A. According to that theory you also should be able to SSH from your Raspberry to router B if rules allow it.
  • you PC is on another subnet then DMZ and router A forwards the package into the DMZ according to its routing table to router B. But the package won't find its way back since router B has it's own routing table. And that forwards the package to router B's WAN port because the dest IP address is not its own LAN net.
  • your PC can reach the Raspberry since all traffic to and from the Raspberry will go through router A. The Raspberry has probably only one routing table, which is all traffic to router A.

Using tcpdump you could verify it the above is the case or not (I could easily be wrong). Connecting the WAN port to the DMZ would still be my way of doing it.

Otherwise you add a route to router B which sends packages from the home network address range to router A.

No problem!

That is an explanation that really makes sense to me, although I am not the world's greatest routing specialist. :slight_smile:

That is the solution I would prefer, as a temporary measure to ease the setup process. I could ssh into router B from router A and add that route on the command line, so it will not be a permanent route after reboot. Then I should be able to reach the luci router B from my pc. Right?

Yes, exactly. You can make it a temporary rule or permanent rules you remove after setup.
I'm not really a routing specialist myself either :slight_smile: ... but something along the line should work for a temporary route:

On router B:

  • get the current routing table (just so you know the "before":
    ip -4 route show
    ... there should be a rule for the LAN like:
    2.2.2.0/24 dev br-lan scope link src 2.2.2.20
  • add a route to you home network via router A (assuming router A's DMZ IP is 2.2.2.1):
    ip route add 1.1.1.0/24 via 2.2.2.1

Additional comment: As @jaromanda wrote, it's not a good idea to use public ip ranges for your private network. There is for example Cloudflares public DNS service with IP 1.1.1.1 which you won't be able to use. And more importantly if you configure anything wrong in you home network, your private traffic will go out into the world.
So if you use the two IP ranges only as an example to explain the issue then all it good :).

Sorry for the long delay. I did not yet get to it, but setting up that router is on top of my todo list...

But in the mean time I want to answer your and jaromanda's objections regarding the IP range I use: those IP numbers shown above are just place holders and are not actually in use on my router. Their appearance here is just the result of my laziness when it comes to typing those numbers. :wink: