Preventing access to secondary firewall
-
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...
-
Most people do not pass traffic in WAN to the inside network so it is not a problem.
You will have to look at the states to see why the traffic is not being blocked on the LAN interface of the secondary. Something tells me traffic is not flowing like you think it is.
-
This is a toy example meant to illustrate the problem. You've said both that a rule would be needed on the WAN to the secondary firewall's LAN interface, and also that you think the rules on the LAN interface should block it. I can't tell if you're saying this is expected behavior for it to not be blocked, or not.
I agree that most people are probably not allowing full traffic from the inside to their outside. However, the reverse is certainly common (allowing all from the inside to the outside) - some environments may have an allow all out to the outside. In that situation, even the block to This Firewall will not stop the inside clients from reaching the outside interface of the secondary firewall.
It becomes even more difficult in situations with multiple inside interfaces... hence me wondering about whether I really need to create an alias all of both firewall's IP addresses, and block that instead. I don't think most people are going to work through that and realize their secondary firewalls' interfaces are unprotected.
If you set it up in a lab, with NAT turned off and state syncing turned on, I think you'll see that it behaves the way I'm describing it.
-
I am not going to set it up because I am certain that I will not see it as you are.
NAT has absolutely nothing to do with hosts on inside interfaces accessing the firewall's outside interface address.
Then you are not misunderstanding something very basic or have something else misconfigured. A synced rule blocking access to This Firewall (self) will absolutely block traffic to the primary on the primary and the secondary on the secondary.
Please send me the contents of /tmp/rules.debug from both nodes in chat and explain exactly what you think should be being blocked in the real world situation that is not being blocked. Please be as specific as possible. Source and destination addresses, etc.
Thanks.
-
I cannot send you our production rules, but we've tested and confirmed this behavior on three different clusters. The best I could do is set up a lab, confirm the behavior, and send you that config. If time permits, we will do that.
I mention NAT only to make it clear that NAT is not involved in our scenarios, since you've asked me about it several times.
@kayavila said in Preventing access to secondary firewall:
I can't tell if you're saying this is expected behavior for it to not be blocked, or not.
Would you please confirm if you think the traffic should be allowed or not without explicitly blocking the secondary IP addresses?
-
This firewall rules sync from the primary to the secondary. It covers the interface addresses on the firewall upon which the rule is active.
-
@Derelict said in Preventing access to secondary firewall:
This firewall rules sync from the primary to the secondary. It covers the interface addresses on the firewall upon which the rule is active.
Also if I'm not mistaken, "This Firewall" also includes all CARP VIPs of the firewall as well as any firewall related IP. We have quite a few clusters here, that are configured that way to block certain things or allow certain things with This Firewall as it includes the VIP as well as the node IP on the corresponding node so if you e.g. configure an allow or block SSH with that it covers all 3 IPs in a typical CARP setup.
-
@JeGr said in Preventing access to secondary firewall:
This Firewall as it includes the VIP as well as the node IP on the corresponding node
This is not correct. It does not include any of the secondary member's IPs when being evaluated on the Primary. and vice-versa when being evaluated on the secondary.
-
We had a chance to set this up with two lab firewalls and a very basic config and were able to replicate the behavior. I've uploaded the configs to @Derelict but I can post them here as well if people are interested.
The issue with accessing a secondary firewall's interface by passing through the primary only happens if state syncing is turned on. From looking on the command line and in the web interface, I thought that states held in memory were specific to the interface, so I'm not sure why this works.
@JeGr I would be interested if you have the chance to test with your clusters on something similar to what I'm talking about, if you're similar enough to the setup I described where you're using a VIP. If you have something that's allowed all on your LAN interface, even if that rule is after your blocks to the firewall, can you hit the secondary firewall's WAN interface? (Or vice versa, as I was describing above, with a rule from the WAN to something on the LAN.)
-
@IcePick said in Preventing access to secondary firewall:
This is not correct. It does not include any of the secondary member's IPs when being evaluated on the Primary. and vice-versa when being evaluated on the secondary.
Never said that - read again :)
-
We created a lab with two firewalls with very basic configs, and set up something similar to what I outlined above. I provided rules and config to @Derelict at the beginning of July and messaged him since to follow up but haven't heard back. So, I'm uploading them here.
Using these configs, the IP address in the test alias (from the outside/WAN interface of the firewall) can connect to the secondary firewall's LAN interface, even though the rules would seem to block it.
Additionally, any IP address on the LAN subnet can connect to the secondary firewall's WAN address, even though the rules would seem to deny it.
If you turn off state syncing, this stops being true.
I'm interested to see if anyone can find an issue with how the config is set up, or whether using "This firewall" in the rules just isn't enough to ever block access on the secondary.
fwa_rules.debug.txt
fwb_rules.debug.txt
config-fwa.localdomain-20190627095630.xml
config-fwb.localdomain-20190627100039.xml -
K kayavila referenced this topic on
