I am trying to get a nested network to connect to the internet without masquerading at each step. That is, the second network getting online with a single NAT at the main router.
Here is the setup:
internet <-router1 with NAT-> network1 <-router2 without NAT-> network2
If I put NAT on router2, I get proper access. If I directly connect it so hosts can see each other, no internet.
I have set up proper routes. There are other networks connected to router1, and they all communicate properly with each other and network2 . Router2 gets to the internet. Network2 gets to the internet when masqueraded but not when not masqueraded. Network2 gets to router1 when not masqueraded and masqueraded.
I have pinpointed the issue to router1, especially its NAT configuration. I have set accept input and forward for all that comes from network2, and of course the NAT masquerade with similar setup to network1, but network2 addresses. If I have missed anything, I am not finding a guide in the first pages of websearch.
Actually it is hard to say what is the problem. You could have set dns or dhcp or ip addresses wrongly. Generally it is not recommended to make multiple nested natted networks as routing between subnets is much more transparent and effective.
If the only difference between working and non-working is masquerade rule on router2, and if network2 can communicate with router1 in both cases, then it sounds like routes are ok and problem should be something on router1. Basically it should be either traffic from network2 being blocked in forward chain, or not catched by masquerade/snat rule.
It should be fairly easy to debug. If you try to connect from network2 to some external address, you know where you should see those packets on router1. So just add logging rules to prerouting, dst-nat, forward, src-nat and postrouting and see how far packets get. Limit logging rules by specific target address (you can use e.g. 1.1.1.1 for testing, you won’t be able to connect to it, but you will see if properly NATted packets are leaving router1) and then try to connect to it from network2 (using anything you want, telnet, browser to http://1.1.1.1, etc…).
I do not know what changed, probably some timeouts in the caching in the switches in network1 or network2, but the configuration that was not working yesterday just worked today as the workday started, as it should, since it is not something difficult to pull hair out and it should have worked in the first place.