I am using OpenWrt as a standalone firewall just behind my ISP's modem/router.
OpenWrt has three physical NICs for the three zones: WAN, LAN and DMZ.
In standard (default) configuration WAN has "Masquerading" ticked (and apparently it is really required since turning it off won't work).
Question is: why is that required?
In my case ISP's modem/router already does NAT and presents itself as "valid"(although non-routable) 192.168.1.1; why do I need a second NATting (or did I misunderstand the concept) ?
You do not need a second NAT, as your ISP modem already does that NAT.
But OpenWrt default config starts from the assumption that the router is the outermost device and takes care of the NAT for LAN. If that is not needed, you can change the config from default.
You should be just fine without NAT, but you need to make sure that there is a different subnet on both sides of the firewall, so that both do not have 192.168.1.x. (masquerading is not needed if you fulfill the requirement by defining subnets otherwise.)
You can disable NAT masquerading on your OpenWrt wan firewall zone as @hnyman stated, but you must setup a route on your ISP router accordingly, otherwise that router will not know where to send traffic.
For example:
Let's asusme your ISP router is using address 192.168.1.1 on the 192.168.1.0/24 network
Your wan interface on your OpenWrt router might be 192.168.1.2
You'll need to make sure that the OpenWrt lan is a different subnet, so for example, it might be 192.168.5.1 on the 192.168.5.0/24 network
From there, you'll need to set a static route in your ISP router (assuming it supports user-configured static routes) as follows:
Also you'll need a static route in the first router for each LAN in the second router -- 192.168.7.0/24 and 192.168.9.0/24, are both reachable with 192.168.1.253 as the gateway.
I have OpenWrt (my Firewall) as default gateway for both internal nets (LAN and DMZ).
OpenWrt has ISP modem (handling NAT) as its default gateway.
This should be enough to route outgoing packets to Internet through Firewall and ISP modem.
Only problem there is all internal nets are in the 192.168.x.0 range and are, by default, "non routable" and thus I should "convince " OpenWrt to route them. Is this the done using the "static routes" @mk24 is speaking about?
In the other direction (connection attempt from the Internet) I have OpenWrt as "DMZ Host" on ISP modem, so any incoming packet is (after NATting) sent directly to OpenWrt who should do DNAT and send it to handling server (or dump it if no server is defined for port).
To be clear, the term "non routable" for RFC1918 address refers to "non routable on the public internet." They are fully routable within the context of private/local area networks connected to each other in some way that is not via the internet (unless a VPN is involved).
You do not need to "convince" OpenWrt to route these networks, you just need to make sure that the routers involved all understand the neighboring networks and the gateways to get there. That's what static routes are about.
In my example from earlier:
All of the devices on the 192.168.5.0/24 network exist behind the second router. When masquerading is enabled, any traffic that is sent by (and responses to be returned to) hosts on that network will masquerade as traffic from/to the second router itself (192.168.1.2). That is to say, as the packets egress from the second router towards the upstream/first-router, the packets are re-written to use the second router's wan address (192.168.1.2) as the source address of the traffic, instead of the 'true' source address from 192.168.5.0/24.
When you turn of masquerading on the 2nd router's upstream firewall zone, the packets are no longer re-written, so the 'true' source address is maintained through the 2nd router's wan. That means that the upstrea/first router sees packets that have a source address from the 192.168.5.0/24 network. This is fine... but, when the response comes back -- now with a destination address on the 192.168.5.0/24 network -- the upstream router only knows about 192.168.1.0/24 and it has no way to send the 192.168.5.0/24 traffic to the right place, so the packets just get dropped.
This is why you need to make sure that the upstream router is aware of the existence of the downstream network and knows where to send that traffic. In this case, the upstream router knows it can send packets to any device in the 192.168.1.0/24 network. So we now add a route:
This says "if you have a packet that needs to be sent to the 192.168.5.0/24 network, send it to192.168.1.2 and that device will take care of the rest"
Yes.
Now I understand (at least this part, many other things need further study, of course).
This also means I will have to live with Masquerading because I see no way to add static routes to my ISP modem ("first-router" in your terminology) it is a "TIM HUB+ ZTE H388X" which doesn't seem to be supported by OpenWrt, unfortunately.
I might be able to convince it to work as "pure modem" via PPPoE, but I'm unsure.
Other thing (but I fear we are O.T. here) is this modem/router seems to support some kind of "topology" setting and I wonder id OpenWrt could present itself as "router/repeater" instead of simple "device".
I have no knowledge of that device, so I can't comment about the configuration options that are exposed to the user, but yes, it seems like you may not have the option for static routes. Feel free to post any screenshots from that device that look potentially relevant and we can try to advise if that might be possible.
To me, the topology thing doesn't look configurable and really seems to simply show you the upstream and downstream devices.
That said, if your ZTE device is actually performing routing functions and you don't need OpenWrt's routing layer, you can simply configure OpenWrt as a dumb AP -- this means that OpenWrt is purely a transparent ethernet-wifi bridge device with no firewall or routing functionality enabled.
Thanks @psherman,
I was unclear.
I do need OpenWrt routing layer (if I manage to master it, of course) for several functions (and AFAIK only the first one could be achieved with "first firewall"):
Redirect requests incoming from the Internet to server suitable to handle them.
Separate Internet server(s) in a DMZ zone where they cannot access internal LAN even if/when compromised.
Manage my TWO ISP connections (handled by identical modem/routers).
Handle a handful of VPNs I have.
Provide a Bastion Host to protect internal net.
I was under impression "first firewall" is using some sort of discovery protocol (SNMP? LLTD? other?) to determine "Topology" and I was wondering if OpenWrt could handle such protocol.
Yes, it seems like you do indeed need the features of OpenWrt based on your list
Honestly, I suspect it is more simple than that... it's probably either pulled from the DHCP lease table (for any DHCP clients behind the ISP router) and/or an ARP listing. And yes, OpenWrt can do that, but it doesn't have an easy way to show what is connected via ethernet vs wifi (it wouldn't be terribly hard to deduce that information since you could compare the wifi clients vs all clients lists).
I don't think is DHCP as OpenWrt has fixed address and doesn't rely on DHCP client (I'm not using ISP's DNS servers).
WiFi vs. Ethernet isn't an issue in my case as WiFi stuff is not handled by OpenWrt which has only Eth (wired) interfaces. My A.P. is an external device sitting on LAN.
If you can point me to relevant documentation about how "OpenWrt can do that" (or directly explain, if simple enough) I'd be very grateful.
I meant:
How can OpenWrt (if it can) provide this kind of information to "first firewall" so it can understand openwrt is not a simple host but a router/repeater itself and thus it indeed is a "second firewall" who can can route packets to other hosts (currently invisible to "first firewall")?
I'm not sure what mechanisms would be available in general, but in your specific case, it can't in the context of the limitations of the ISP device since there isn't a way to set static routes. You must use NAT masquerading, which by definition means that the OpenWrt device abstracts the devices behind it. From the perspective of the ISP connection, it is just one device and there is no way to provide information about what is behind the router.
)