Firewall Aliases IP Addresses with Port Forwarding

NVDude

pfSense+ 24.11 on Netgate 7100
I successfully forwarded a port from the public internet to a LAN host. This was set up as a linked rule (Firewall...NAT...Port Forward), initially with source address * (any). I then wanted to limit the IPv4s allowed to connect to members of a small list, so I created an alias in Firewall...Aliases...IP and added the IPv4 addresses. In the firewall rule I changed the source address to the name of the firewall alias.
This did not initially work (traffic not forwarded), because when I first entered the IPs in the alias I used only the address e.g. xxx.xxx.xxx.xxx. However, after I re-entered them with a CIDR mask they worked e.g. xxx.xxx.xxx.xxx/32. It's worth noting that after saving the alias, the IPs do not display the mask, so it looks the same as when I entered them without masks.
The relevant documentation seems to be at https://docs.netgate.com/pfsense/en/latest/firewall/aliases-types.html#alias-types-host . Although it says IP ranges may be used, it doesn't specify that a /32 mask must be used for individual addresses.
I don't know whether this is a documentation issue, or if something is not behaving as expected. In any case I thought I'd bring it up so it doesn't bite anyone else unnecessarily.

patient0

@NVDude and you really did use type 'Host(s)' for the alias? For me that works without a mask (as pictures in the documentation).

Maybe post screenshots of the alias and the firewall rule it gets used. Make sure you blur out public IPs.

NVDude

@patient0 Yes, the alias is of type "Host(s)".
There seems to be some processing happening when an alias is created or modified, after the Save button is clicked. For example, if an IP address range is added e.g. 10.11.12.13-10.11.12.16 then it gets translated to 4 individual entries:
10.11.12.13
10.11.12.14
10.11.12.15
10.11.12.16
which is as expected and as documented. If a description was added, that description is copied to all 4 individual entries.
Now I'm wondering if my issue is an edge or corner case of this processing.
The full history of this alias - in each case the alias was edited, not deleted and re-created from scratch:

Version 1 - 2 hosts:
IPv4 address #1 (without mask)
FQDN (which the firewall resolves on the fly to one IPv4 address)
Result: traffic from the FQDN forwarded as expected, traffic from the IPv4 not forwarded

Version 2 - 3 hosts:
IPv4 address #1 (without mask)
IPv4 address #2 (without mask)
FQDN (which the firewall resolves on the fly to one IPv4 address)
Result: traffic from the FQDN forwarded as expected, traffic from both of the IPv4s not forwarded

Version 3 - 3 hosts:
IPv4 address #1 (without mask)
IPv4 address #2 (without mask)
IPv4 address of the FQDN (instead of the FQDN itself)
Result: traffic from any of the IPv4s not forwarded

Version 4 - 3 hosts:
(deleted existing hosts and re-entered as below)
IPv4 address #1 (with /32 mask)
IPv4 address #2 (with /32 mask)
IPv4 address of the FQDN (with /32 mask)
Result: traffic from all IPv4s forwarded as expected

Some notes:

The IPv4s I used are all public, whereas the examples used in the documentation are all private
If anyone wants to try to reproduce, I imagine any FQDN the firewall can resolve to a single IPv4 will work
Maybe test using port forwarding rather than using the alias in some other context, in case the issue is specific to that

For those who have followed along, thanks ;)

patient0

@NVDude that is a such a basic and often used feature and I can't remember having heard anyone having an issue with.

I tested version 1 and it works, not port forwarding but block access to these IPs.

What is the output of pfctl -t <alias name> -T show? Again, if necessary blur public IPs you don't want to be known. The command will show you the IPs in the alias and if they are what they are supposed to be.

SteveITS

In the firewall rule I changed the source address to the name of the firewall alias.

Do you mean the source of the NAT rule? If not, try that.

NVDude

@SteveITS Sorry for the delay but I believe I have a repro.

Firewall rule already present, in my case for port forwarding. This rule was originally created with Source "Any" (the default) but was later edited to use a list of hosts in an alias (advanced options)
Create a new test alias, type Host(s), with a description
Add first host (IPv4 address #1), with a description
Add another host (FQDN resolvable by the firewall), with a description
Save the new alias and apply changes
Edit the NAT rule: In Source section show advanced, change the source type to Address or Alias, start typing the new alias name, select it from the dropdown when it appears
Save the rule and apply changes
Result: I can connect to a host on the remote LAN via port forwarding from the FQDN (as expected)
I'm currently not able to test from the first IPv4 address but users at that address could not connect the first time I set this up. That led to this whole investigation
Edit the test alias:
Delete the FQDN host
Add a second host, another IPv4 address, with a description
Add a third host, the public IPv4 address of the FQDN, with a description
Save the changes to the alias, and apply changes
Expected result: I can still connect to the remote host because my FQDN's IPv4 address is in the list of hosts
Actual result: I can't connect to the remote host
Again, I can't test from the other IPv4s on the host list but they could not connect in the earlier iteration

In case it matters. the firewall open port is 8086 and it's forwarded to 443 on the internal host. SSL/TLS is not properly configured on that host so a browser is warning "Not secure". When I'm able to connect I can get to the host sign in page. When I can't connect the browser reports "This site can't be reached...took too long to respond".

I'll retain this "bad" alias in case it's needed for further investigation.

Thanks again to anyone sticking with this.

SteveITS

@NVDude By default pfSense creates a firewall rule for a NAT forward so there should be no need to edit separately, and in the above order it’s edited first.

That default can be disabled on the NAT rule.

NVDude

@SteveITS I'm not sure what you're referring to. In case it matters I'll recap my whole process:

I created a port forward following the steps in https://docs.netgate.com/pfsense/en/latest/nat/port-forwards.html . This created what's shown as a linked rule in Firewall...NAT...Port Forward
By default this creates the rule with source "Any"
To lock things down we wanted to change that so the source would be only a list of a few IPv4s, rather than the whole world
Since an advanced option for Source is to use a host names alias, I created an alias with those IPv4s
I then edited the rule to use that alias instead of "Any"

This process makes sense to me, and it does (eventually) work as expected, but should I have been doing it differently or is there something I missed?

This might be getting deep in the weeds but in case it matters here are some other points specific to this device config:

In the list of Firewall...NAT...Port Forward, there are 4 disabled rules (for different public ports) above the only active rule
I may have created the active rule by copying one of the currently disabled ones

Sorry to keep bombarding you with more information but I don't know any other way to track down potential edge and corner cases.

Thanks again.

Bob.Dig

@NVDude said in Firewall Aliases IP Addresses with Port Forwarding:

By default this creates the rule with source "Any"

Be default, any rule has any in it, regardless. You are able to change the source in the NAT-rule too. So everyone is wondering why you didn't do that and fiddle around with the linked rule instead.
But I also did this in some cases, for better visibility, especially with different aliases which I didn't wanted to combine, so I created the same firewall-rule but with different sources three times or whatever.
But for best efficiency you do it right in the NAT-rule because then the not-matching traffic doesn't get NATed in the first place, I guess.