Preventing access to secondary firewall
-
What's the best practice for blocking access to the secondary firewall in an HA pair?
In situations where I want to give an IP address access to an entire subnet, but block management access to the firewall, rules like these only prevent access to the primary firewall. Access to the secondary firewall is still allowed with the rules below:
With the above rules, I can still ssh from the test IP address to the secondary firewall's LAN address, presumably the primary firewall allows it through and then the state is synced as an allow to the secondary firewall. Instead of using "This firewall" in rules to block access, do people create an alias with all the interfaces and CARP IP addresses for both firewalls or is there a better way?
-
If you want to have access to multiple IPs create an alias with all, but only use CARP VIPs. CARP VIPs are assigned to the master at every time.
-
That's not quite what I'm trying to do. In the above rule, I'm trying to give the host in the "test" alias access to all of the servers on the LAN net, without giving it access to the secondary (or primary) firewall address. But as is, the rules prevent access to the primary but allow access to the secondary.
-
I misunderstood.
I have copied your rules and tried it out here. But it's working as expected.Maybe you have the Anti-Lockout rule active on the second box. The Anti-Lockout setting isn't synced to the other box by XMLRPC Sync.
-
Good idea about the Anti-Lockout. I double-checked though and it's disabled on both boxes. We've also verified this behavior across multiple clusters running 2.4.4-RELEASE-p2.
Did you set up something similar to my example above but you were prevented from SSHing into the secondary firewall from your "test" IP?
If it makes a difference, in my setup traffic would be coming in through a VIP to the primary firewall and then routed over to the secondary firewall.
-
@kayavila said in Preventing access to secondary firewall:
That's not quite what I'm trying to do. In the above rule, I'm trying to give the host in the "test" alias access to all of the servers on the LAN net, without giving it access to the secondary (or primary) firewall address. But as is, the rules prevent access to the primary but allow access to the secondary.
I would check that again. This Firewall will do the same thing on the secondary when that rule is synced from the primary. It will mean all of the secondary's interface addresses there.
If it makes a difference, in my setup traffic would be coming in through a VIP to the primary firewall and then routed over to the secondary firewall.
If it is being subjected to Outbound NAT, then that is the source address you will have to block from on the secondary.
-
@Derelict said in Preventing access to secondary firewall:
I would check that again. This Firewall will do the same thing on the secondary when that rule is synced from the primary. It will mean all of the secondary's interface addresses there.
I'm certain Anti-Lockout is disabled on both boxes.
We're hypothesizing that this is related to state syncing, which is turned on in our pairs. This Firewall corresponds to the secondary's IP address(es) in the rules on the secondary, but in this case, the rules on the secondary are never evaluated. The primary has already allowed the traffic through and synchronized the state. The secondary sees the traffic as an existing connection and permits it, without ever checking it against the rules.
If I turn off "Synchronize states" under System -> High Availability Sync, I no longer see the traffic being permitted to the secondary. The secondary's rules are evaluated and the traffic is blocked.
@Derelict said in Preventing access to secondary firewall:
If it is being subjected to Outbound NAT, then that is the source address you will have to block from on the secondary.
True, but there's no Outbound NAT in our setups.
-
Why are you not connecting directly to the secondary then? Why are you going through the primary? That usually creates an asymmetric routing scenario at best.
-
I'm trying to prevent other hosts from being able to access the secondary's interface. So this is about traffic that I would like to be prevented, but doesn't seem to work the way I would have assumed it should work (before we started digging into it).
Likely other people are assuming This Firewall works the way we originally did, and believed their secondary firewalls had protections in place to limit management access. It doesn't appear to work that way. This should probably be called out in the documentation.
I'm wondering if this is something that's generally known and people just create an alias with all of the firewalls' IP addresses and VIPs and block that rather than using This Firewall, or if there's something we're missing.
-
@Derelict said in Preventing access to secondary firewall:
Why are you not connecting directly to the secondary then? Why are you going through the primary? That usually creates an asymmetric routing scenario at best.
Just to clarify and answer your question, we route all traffic through the VIP on the WAN interface of the clusters, so that we can have fast failover. So traffic to the LAN interface of the secondary would be routed through the VIP (currently living on the WAN interface of the primary) out through the primary's LAN interface to the secondary's LAN interface.
-
Right. A scenario similar to this:
https://docs.netgate.com/pfsense/en/latest/highavailability/troubleshooting-vpn-connectivity-to-a-high-availability-secondary-node.html?highlight=access%20secondary
Outbound NAT is the solution there too.
-
@Derelict No, I don't think so. That link describes a situation where "one can communicate with the master but the backup node is unreachable."
We have connectivity just fine. Connectivity isn't the issue. The issue is the rules not blocking the traffic.
-
You need to explain your situation exactly. In a situation where the client is directly on the LAN side of the HA cluster, the rules work fine. How is your client reaching the LAN side of the firewalls?
-
I'm not sure how else to explain the situation aside from the first screenshot and my walkthrough explaining how the traffic is routed, but I'll try. The above screenshot is a simplified example, but one that we've tested and shows the behavior.
In a nutshell, I would like the addresses in test to be blocked from accessing the secondary firewall's LAN address, while being able to access other servers in that subnet. The rules certainly block access to the primary firewall's LAN address. However, they permit traffic coming from test to access ssh on the secondary firewall's LAN address.
In this setup, primary and the secondary are set up in a cluster, with traffic being routed through a VIP that's currently active on the primary firewall. The firewalls are set up to synchronize state.
This is only an issue when state synchronization is turned on.
-
Where do the addresses in test come from? A tunnel? Another directly connected interface? A router on the LAN?
-
@dotdash said in Preventing access to secondary firewall:
Where do the addresses in test come from? A tunnel? Another directly connected interface? A router on the LAN?
A subnet outside of the firewall environment, not directly related to the firewall in any way. They would be routed through but not originate from a router on the LAN. In this particular case, I used a wireless address from my laptop to test. It was routed through our internal environment to the pfSense pair's uplink router and ultimately to the pfSense itself. There's no VPN or tunnel involved.
However, test could represent any IP address external to the environment. The goal is to allow external entities access to the LAN subnet while still protecting both firewalls' LAN interfaces.
These are not my actual IP addresses, but for an equivalent example, say 10.0.0.0/24 is the subnet between the pfSense pair and their upstream router. 10.0.0.1 is the upstream gateway router. The primary firewall's address is 10.0.0.101, the secondary is 10.0.0.102, and the VIP address is 10.0.0.100. On the LAN subnet, the primary firewall is 172.168.0.2, the secondary is 172.168.0.3, and the VIP on that subnet is 172.168.0.1. The IP address in test could be 192.168.0.1. Currently (with the rules in the screenshot above) it can access 172.168.0.3.
-
The rule blocking the traffic will have to be on the secondary's LAN interface because that is where the traffic is arriving on the secondary.
Or you will have to create a rule on WAN that specifically blocks traffic to the secondary's LAN interface address. This Firewall (self) on the primary will not include that address because it's not on This Firewall. Having the rule on secondary's WAN will not do any good (unless that firewall holds the CARP VIP) becaue the traffic is not arriving on the Secondary's WAN, but on its LAN via the primary.
-
Yes, that's an excellent point about the WAN address. I forgot to mention that there's a rule there that should be blocking access. I'll include a screenshot below.
Here's a diagram that might help. Traffic is taking the red dotted path. First it encounters the LAN ruleset on the primary at point #1 (screenshot below), then it should encounter the WAN ruleset at point #2 on the secondary.
When state synchronization is turned on, the rule at #2 doesn't appear to do anything, and the traffic from test to the secondary's LAN interface is allowed, presumably because it matches an existing state. If I turn state synchronization off, it begins blocking it.
Rules from the WAN interface (step #1):
Rules from the LAN interface (step #2):
-
@kayavila said in Preventing access to secondary firewall:
First it encounters the LAN ruleset on the primary at point #1 (screenshot below), then it should encounter the WAN ruleset at point #2 on the secondary.
Actually you have that backwards. It encounters the primary's WAN rule then the secondary's LAN rule.
If you think it is matching a state, connect and see what the state table says?
In general, what you are doing will not work because the reply traffic from the secondary will take the default route back to the test host and you will have asymmetric states which will fail, so you must have something else in play here. Unless you perform outbound NAT out the .2 interface on the primary.
If you want traffic to be blocked, as I have said before, you need to block it with a WAN rule blocking access to 172.168.0.3. (172.168?)
-
@Derelict My diagram is correct, I just typo'ed the interface names in the writeup. Yes, it hits #1 first, the WAN interface, and then #2 on the LAN second.
It works just fine with the asymmetric routes and no outbound NAT, however. The return traffic still makes it back to test.
I realize that adding a firewall rule on the WAN interface will work. That's what my initial question was about... do people just create an alias and include all the firewall IPs (from both firewalls) and VIPs and block that explicitly, or is there a better way to do this? Since obviously this situation could happen with each one of the interfaces...
