We’re currently experiencing an issue with our new setup. I’ve created an image in an attempt to clarify how it looks right now.
Following are assumed:
We own the wan network 100.100.100.0/24
We use this network for our servers (through NAT) and a couple of customers (serving as their ISP)
CCR01 is just “the router” and does nothing special just route.
CCR02 is acting as a routing firewall as well as managing NAT for our internal resources.
CCR02 has forwarded 100.100.100.2:443 to 192.168.0.2:443 for webmail.
Bob the green guy is smart and listening to our directives, using CCR01 as default GW.
Alice the red girl is using CCR02 as default GW instead.
Bob can connect to internet and through the NAT is able to reach 192.168.0.2:443 @ 100.100.100.2:443 for webmail.
Alice can reach internet and go to Facebook, but she can also reach 192.168.0.2:443 (at the local RFC 1918 address) since she’s using 100.100.100.2 as gateway.
Is there any way we can prevent Alice from using CCR02 as gateway? We can’t see a way to block users reaching 192.168.0.2:443 without borking the portforward. (IE we can’t just block access to this IP)
Anyone got any good suggestions on how to avoid this?
Since Bob and Alice and the two routers are on the same layer2 segment, no you have no way of preventing her from changing her IP settings and selecting to use that as the default gateway. You have no way of controlling what users decide to do with their computers.
Why do you need two CCR’s? Each interface is able to act as a separate routed interface, so to simplify things it would be good to remove the second router. You should be more able to firewall things off and control the traffic flow. Though we would need to know more clearly what the design goals of the network are and then appropriate suggestions can be made.
Yes to have only one router is the best solution, this is just a quickfix to avoid the clients to access the inetrnal networks,
What i want is to NOT let other client on the same external subnet to access internal adresses directly.
And if i block let say:
drop forward src-int: wan dst-address: 192.168.0.0/24 the dst-NAT stops working as well.
Do you have any ide how to solve this? Can i do it with firewall rules or can i have 2 routing tables one for intenral networks and one for external that just can NAT and will not route.
It sounds like you’re using NAT as a firewall - basically, using the fact that server 192.168.0.2 has an un-routed IP address, nobody can reach it. You created a NAT rule for a single port 443 to reach this server, expecting that only this port may reach the server.
A slight change in thinking will help - NAT is only to conserve IP addresses / ease IP address changes / allow devices to reach each other without changing the routing table… So what I mean by this is that it is not a filter. That is the filter table’s job. So block all new connections to 192.168.0.2 except on TCP:443. Then you don’t care whether Alice uses the private or public IP to reach the server, because it’s really the same thing anyway, right?
Make a set of filter rules which describe the security policy you want and don’t try to use NAT rules to do this. It works in 99.999% of the cases, but as you’ve just seen, not all cases.
This is why people shouldn’t be afraid of all hosts having public routable IP addresses in IPv6 - firewalls should block unwanted traffic even if the destination host has a private address, because there are ways around the private address problem.
If you want, you can move router 2 “behind” router 1 on a different interface. Create a /30 of private IP space, connect router1 and router2 on this /30, route the 100.100.100.2/32 IP address to the new private IP address of router2. This will also have the effect that you want - namely that 192.168.2.0/24 is no longer reachable from your public segment (because you moved it and didn’t point a route to it) - but like I said above, don’t try to use NAT to filter access to hosts. Use filter rules instead. It makes your network configuration easier to understand because your policy is explicitly defined, and easier to troubleshoot because port blocking happens in a specific place where it’s expected to happen, and not as a side effect of noodling with addresses / port numbers.
