Firewall Aliases IP Addresses with Port Forwarding
-
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. -
@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.
-
@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 forwardedVersion 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 forwardedVersion 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 forwardedVersion 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 expectedSome 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 ;)
-
@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. -
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.
