Floating rule(s) for firewall (localhost+proxies) access
umademelosemyusernamepfsense last edited by umademelosemyusernamepfsense
I want to create a floating rule to access the firewall on all its ports but avoiding it would create asymmetric routing.
I was aware that floating rules don't create Reply-To rules, but I figured, since the rule would be to the firewall itself, it might not need any. I'm not sure about that.
I'm going to create another firewall but it's got only a gigabit link back to the core, so routing between VLANs will be left in the old firewall, future just router. I need to create new rules for the new edge firewall without interVLAN comms. There are way too many subnets and a [set of] floating rule(s) would take much less time to do. Otherwise it's rules for 20+ interfaces.
The way I'm seeing it, it's like this:
But y'know...enabled. Only IPv4 because there's basically no NAT on v6 and it's a rule fest. Maybe after Suricata is retrained.
Floating rules have a direction bit, as you know, so if I craft a rule like this, should I make only in the IN direction like a normal interface rule would be? Or, if I do that, it would rule out, so to speak, the OUT direction as I would be explicitly indicating direction, disabling clients on the different subnets to communicate with the firewall and ANY of the services it might run or --the most confusing part-- proxy. The directory service is running at the naked domain level, a no-no in directory services and sure enough I've had issues but found ways to manage them all. One of those was using the naked domain to host a website without exposing directory servers, outside the network plain NAT solves it easily.
Inside there's really no need to protect the directory servers, but the addressing becomes an issue if it differs from outside. Web traffic to the naked domain is intercepted and redirected by HAProxy (with SNI of course, not transparently). If I create a floating rules going ANY, what's allowed to come OUT? In other words: is HAProxy considered localhost or is it attached to a subnet from/to where it proxies. Furthermore, HAProxy isn't even the only thing acting on-behalf-of on the system, there's Squid too, necessary for Squidguard. DNS is a very complicated mess, probably the hardest, port 53 is blocked on the edge, pfSense isn't allowed to resolve using external nameservers nor itself, only from domain controllers, but it does run both BIND and Unbound and has several interface pairs that are just loops to even more DNS servers, so when there's a power outage and the hypervisors are just starting to load VMs, still with no VPN links up, and no DNS/TLS translators, pfSense is able to dial the links and get stuff back online. Should I create static routes in pfSense with the actual default gateways on the other device handling interVLANs so pfSense stays as default gateway for clients? Should it stay as the default gateway for clients?? Is there maybe some way to split the logic of pfSense without HA, GRE perhaps--like virtualized networks do? How far "localhost" reaches, I know-I know 127.0.0.0/8, but when it proxies or in the instances where it's allowed to route, how IN or ANY-direction floating rules behave?
When you really think about it, it gets really complicated real fast -- it gets me a little anxious/flustered. One step at a time, though; would a floating rule like this work? Please say yes with not "but…"s. :)
I guess checking the box of ignoring rules on the same interface would solve all of this, but after reading the book I sort of got the message that that's sloppy, and I rather suffer a little and learn to do it right--if I can... Routing is easy but asymmetric routing is easier. There was this time where I actually drew pipes (as in tubes) to understand my own ideas. :/