None of that has anything at all to do with NAT.

True. This part doesn't. However, the part that does, which is what I meant, is the part about punching a whole through the firewall, which I gave above in the post.

From post #6, this thread:

There's a command, that punches a hole through the firewall, in NAT.

To make things route through with NAT, you first add the route command, then you add this command (the simplest form of how you can do it). Then, even though there's NAT, the two portions of the larger network can talk to each other completely. Both sections can have Internet access through the main router. Things like SMB will work fine through it, without port forwarding. You can ping any address on either side from either side, unless you have it disabled from the device itself.

...

However, he/she's asking if we can make that work in Router mode, and hoping that it will allow SSH to know where things are coming from on the network, rather than thinking they're coming from the external network.

My first input (post #6), was because, maybe they don't really care if there's NAT, like I didn't for now. Maybe my solution that I discovered would do what they wanted. Those things were untested on my network.

My question here was, "What if we used normal IPs, instead of special IPs on the second router, and had things in router mode?"

In my experiments, I had gotten the same to work in router mode, but the traffic behind the second router, wouldn't connect to the Internet. I was wondering, if I changed my IPs to normal IPs, instead of non-routable IPs, if that would have worked the same way, and would have been better than punching holes through the firewall in NAT mode. It would have allowed even more through, I'm sure. But I was wondering if that would have worked.

First, rknichols, you were able to tell me that we indeed DO need to add the route command to the router, like I tried to do too. We are now able to determine, that it was identical to MY router route command.

I thought from memory, that I did the same thing, assuming without knowing that I would have to put in that route. I could be wrong, but I'm thinking I might have put in that route. Whatever I did, it could talk to the other things from LAN, across WAN to LAN through the second router, but the traffic behind there could not talk to Internet.

I never tried using a normal IP, so if I'm right from memory that I put that in, then I'm wondering what would have happened if I put in a normal IP range? Maybe I'm wrong though, and I never put in the route command when it was in router mode...

If you know the answer, that's great. If you don't, it will take time, but I suppose I can test it without much lost but time and temporary service outage. Either way, we can try to bring the thread starter an answer of how to make Router mode without NAT, or at least tell them that it doesn't seem to work the way it's recommended.

Then, the thread starter can try it, and see if it solves his problems. And I can decide whether doing things this way or not, is a better design than what I ended up with before.

But for me, maybe it's not a better design for now. On clientrouter, it's not, because as tested, when you separate the IP ranges, airprint will not work. Everything that airprint goes through, has to be flat, without buying more equipment. Buying more equipment isn't right for now. On guestrouter, it might be a better design, but I don't know yet. The thing that will answer that, is the same as part of the answer they are seeking.

If I don't find an answer, it's going to be no big deal for now to have this design. But if I can find an answer, it will be better. For them, it's important. It never hurts to learn more too though.

Hope this helps you help, them/us/everyone.

No more replies. So, since I have the capability to test it, without breaking too much, I'll test it to find the answer to my question. I was a little busy with this:

http://smileynetmain.createaforum.co...s-10-share(s)/

...

But now, I'm not busy with that. So now, I can work more on this. I had to wait to see if anybody else replied anyway!

It occurs to me that in the scenario I posted in #9 you will have asymmetric routing. Packets from a host in the 192.168.22.0 network to a host in the 10.0.0.0 network will go Host_192 => Router 2 => Host_10, while the reply packets will go Host_10 => Router 1 => Router 2 => Host_192. The firewall in Router 1 could be configured in a way that would block that reply since it is not part of an established connection, but that firewall configuration would also prohibit a host on the 10.0.0.0 network from originating a connection to an arbitrary port on network 192.168.22.0. For example, a restrictive firewall that enforces, "Only ports 80 and 22 are allowable destination ports for connections originating from 10.0.0.0 to 192.168.22.0".

Meanwhile, I have no idea how airprint probes for or connects to printers. It does seem strange, though, that a NAT configuration would work and a "router" configuration would not. If anything, I would expect the opposite.

It seems strange to me too, that NAT works, and Router doesn't. I'm going to try to test this, as I repeated in post #22.

As for how airprint works, I've no idea exactly how it works either. But what I know now, is that however it works, without some kind of "repeater", or "proxy", it will ONLY work in one subnet. Not like SMB, which is that way too, but a port forward of a some ports will do. Something about IBG or something like that. That goes beyond my current knowledge, and outside of the scope of what I wanted.

I didn't want to buy a new device for a "proxy", or even set up a server for it of some sort, so I needed to "flatten" the network, for things to work okay. I don't know about working on VLANs. Maybe that's different, but using them for that would completely change the structure of my network and use up IPs in a useless way. Later, if the world got to where a typical home, or home such as mine, would need more than 254 IPs, I'd eventually start to be in trouble. I'd need to learn and use IPv6 earlier than I should. I should learn IPv6, but for now, the practicality of it is uneeded, and I can stick with IPv4.

If I DID get to the point, where I was using > 254 IPs, it will already take some further design to do my network, but that's far in the future. Being wasteful of IPs would make that greater work.

I was glad to see this thread, so I could pass on my knowledge to others, what I'd just learned.

Here goes my test. I may not reply again tell after I'm all done, as my network might ciece to function for awhile...

Alright! Here's my results. I did indeed, break the network by doing this (but no hardware, and physical rewiring was needed).

When you make that simple change to router mode, from the WAN, there appears to be no difference from what I showed you, and in router mode.

But trouble occurs, when you are on the LAN side of that router. The first, is for some reason, DHCP will no longer give out correct gatways to the client. It will try to "pass through". So, you have to manually put in the gateway to give out, which should be the LAN of that router. This, restores full communication with that router from the LAN side, and also allows full communication with the other router on the WAN side.

If you want to block users of this router from Internet, that's one way to do it. They have no access to Internet.

I'm theorizing, that to restore Internet, what must be done is to put in a rule in the routing table for how to get to the WAN, of router1. But when you have a dynamic IP there, it could change at any time. Who knows if it's set up to give IPs from another network/subnet sometime?

So, you would pretty much need a dynamic update of the routing table from the first router to the second, which would add that entry, whenever the router changed it's WAN IP. I don't even know how to begin to do that.

FYI: Changing to a normal IP, rather than an Internet non-routable IP, made no difference whatsoever.

Unless there is some good input on what else I could try for future experiments, my work is done. That's all I know. It appears that it simply won't work without NAT, and that documentation is misleading. It's misleading already, if it's not a straightforward thing to do, really.

To provide this feature with that documentation, and say that's what's recommended, even if there is a way yet to make it work, is a bad idea, if it's not straightforward, and you flip a few switches, and it's done. Why? Well, at least 2 of us on this thread, no more about routing than the average user of routers these days. I knew more to begin with, just had to remember it.

It's not just DD-WRT at fault, it's all the router manufacturers (at least major ones). I've seen the same advice in them, but remember having the same problems, and just didn't bother to try to fix it, because I knew less about how to use the routers than I do now.

If you are reading this DD-WRT maintainers, or others, such as Linksys/Cisco, please, please, please - Change your docs to either recommend that all routers use NAT, with holes punched through the firewall if it's possible, as first recommendation, or b) Add to your docs, a simple tutorial built right in, so it needs no Internet access, that tells exactly how to make it work for the average user, or c) b, and also changing to router mode will pop up a box, saying "this will automatically make changes to other settings, so that the typical Internet connection will still function. Clicking 'Yes', will make these changes. Clicking 'No', will leave you on your own. Clicking 'Cancel', will return you to your previous settings." Make this box pop up every time someone switches to router mode. That's the best yet!

Waiting to see if more people have input, but if not, that may be all the help I can offer. Sorry I couldn't make it work, but at least I offered something for you to try to see if that will allow you to have connections coming from the right place. If nothing else, please try my solution, and see if that does what you want or not.