OpenVPN interface rules not applied to CARP master IP

Michele

I have a couple of firewall with pfSense CE installed using CARP.
There are several OpenVPN servers active on pfSense, one P2P and the others for remote access.
I have a NAT Outbound rule in use to access the secondary node when connected through VPN.

Now I was trying to assign an interface to one of the remote access VPN (used by admins), to have the fw rules for that server separate from the others and to be able to apply an easyrule to that server via cli (because I didn't find a way to choose where the easyrule will be placed, I need it before a block rule)

I have a block rule on top of the default OpenVPN interface to block access to the firewall management ports (ssh, https)

In the assigned OpenVPN interface there is a rule to allow access from the admins VPN tunnel network

It all works as expected for everything but the CARP master IPs. Those connection seems to be filtered by the default OpenVPN interface rules, everything else by the assigned interface rules. I tried with different rules and every rule i put in the assigned interface filter as expected all but the master IPs.

With this ruleset I can't reach the master management ports, if I add an allow rule for the admin tunnel network in the default OpenVPN interface I can reach them even if I explicitly block in the assigned OpenVPN interface.

I found a post with a similar problem but with OPNsense (link), where they say to disable "reply-to" in the assigned interface rules or to disable the automatically added gateway for that interface, but it didn't seems to be related to my problem (tried anyway but nothing change).

Any advice?

Thanks

viragomann

@Michele
The OpenVPN is an implicitly generated interface group, containing all OpenVPN instances, which you're running on pfSense.
The assigned Admins interface is a member of the OpenVPN interface group then.

Filter rules on interface groups have priority over rules on member interfaces.

This means if you have a rule on both, which matches a certain traffic, the rule on the interface group wins and is appled.

So since you have block rule on the OpenVPN tab, it will block any matching traffic.

Michele

@viragomann
Thanks fo the reply

But then why this does not apply for traffic to everything else, only to traffic directed to the master IPs?

If I allow traffic to a certain internal host in the OpenVPN interface, and block it in the other, it is blocked.

viragomann

@Michele
It's not clear to me, what you mean with master IP or CARP IP.

I expect, that your block rule on the OpenVPN blocks TCP packets to any IP on the firewall, either interface or virtual, on the ports contained in the alias.
However, this does not include the interface IP of the secondary node.

Michele

@viragomann
Sorry, I was wrong, if I block any traffic on the OpenVPN interface is indeed blocked.

So the OpenVPN rules are evaluated first, and then if nothing matches the Admin Interface rules are evaluated.

This rule seems to do what I was expecting, to have the traffic from the Admins VPN evaluated on the assigned interface.

I was confused because, since the rules are synced to the secondary node, in theory the "This Firewall" statement include its IPs. I think the traffic to those IPs was not blocked since it is "natted" with the IP of the primary node, to have the secondary reachable trough VPN.

Thanks viragomann

viragomann

@Michele said in OpenVPN interface rules not applied to CARP master IP:

So the OpenVPN rules are evaluated first, and then if nothing matches the Admin Interface rules are evaluated.

Exactly.
For more details check out Firewall Rule Processing Order in the docs.

I was confused because, since the rules are synced to the secondary node, in theory the "This Firewall" statement include its IPs.

No, the alias is called "This Firewall (self)". At least the "self" does not imply that there is anything else meant.
However, I agree, that it would be desirable to have an alias which includes all IPs of the HA pair out of the box.

I think the traffic to those IPs was not blocked since it is "natted" with the IP of the primary node, to have the secondary reachable trough VPN.

The traffic is just routed to the secondary node, which is in backup state.
E.g. if you try to access any IP of the backup outside of the own subnet from a LAN device, the packet is routed to the LAN CARP VIP, since this is the default gateway, i.e. the packet goes to the maser node and is then routed out on the interface, which is in the destination network.

Michele

@viragomann said in OpenVPN interface rules not applied to CARP master IP:

E.g. if you try to access any IP of the backup outside of the own subnet from a LAN device, the packet is routed to the LAN CARP VIP, since this is the default gateway, i.e. the packet goes to the maser node and is then routed out on the interface, which is in the destination network.

Yes, I was referring to the fact that in that case the secondary node sees the traffic as coming from the primary node IP on its same LAN, since is natted, and there is not a block rule in place to access the secondary management IP from the primary management IP.

E.g. traffic directed to the secondary IP comes from the VPN subnet to the tunnel gateway on the primary node, is evaluated against a block rule to filter traffic directed toward "self", but the secondary IP is not "self" for the primary, so it pass and is routed out on the management subnet, natted with the IP of the primary node. There, the secondary would block traffic coming to its IP from outside the management subnet (there is a rule in place), but it appears as coming from the primary IP.

There are more than 50 subnets on this firewalls and quite a bit of rules, so sometimes it takes me a while to get my head around it.

Anyway, thanks for the help. Sometimes all you need is someone with a fresh mind to get you back on the right path.