Firewall Alias not updating table correctly



  • Many of you have more pfSense experience than me so please be tolerant if this is a dumb question.

    I added a Firewall Alias, myHostAlias, containing a single FQDN, myHost.myDomain.com. This router is the handling myDomain.com.

    This command:
    dnslookup myHost.myDomain.com
    Yields, as expected, one IPv4 and two IPv6 addresses:

    Server:		127.0.0.1
    Address:	127.0.0.1#53
    
    Name:	myHost.myDomain.com
    Address: 192.168.xxx.190
    Name:	myHost.myDomain.com
    Address: 2600:xxxx:0:xxxx:e967:afd0:3337:dc72
    Name:	myHost.myDomain.com
    Address: 2600:xxxx:0:xxxx::1:1980```
    

    However when I inspect the alias's table with this command:
    pfctl -T show -t myHostAlias

    It yields only one address:
    192.168.xxx.190

    I would expect to see all three addresses in the table but there is only one.

    It follows that rules referencing the alias are not passing traffic to the IPv6 addresses.

    There is another alias on this router with multiple FQDNs and it creates the table exactly as expected.

    For background, I am using DNS Resolver and there is a domain override in place for myDomain.com (TypeTransparent). It's working as expected.

    Is this a bug? If so, how do I report it? If not, what's wrong?


  • LAYER 8 Global Moderator

    Not exactly sure what your doing.. If you have host overrides already for the IPs why not just put the IPs directly in the alias? Whats the point of having pfsense resolve them itself from its own overrides?

    But also if you have some sort of overlap or something could be related to this
    https://redmine.pfsense.org/issues/9296



  • I found Bug #9296 and posted there. @Justin J sent me here. As far as I can tell this is a bug and a pretty obvious one at that. The fundamental behavior of Aliases creating/maintaining Tables by resolving FQDNs to lists of IP addresses appears to be broken.

    The answer to your question is that the IP addresses can change. When they do, the next Alias refresh should update the corresponding table and the firewall rules should change as well. At least that was my reading of the documentation.

    Bug #9296 is 8 months old and there is no plan of action.


  • LAYER 8 Global Moderator

    I use alias - zero issues..

    They are host overrides - what the F would they change for?

    As to plan of action - looks like to me the targeted version to be fixed in is 2.5, says so right there on the redmine.

    How exactly are you creating your host overide with 2 different IPv6 address anyway.. When I try and duplicate your setup I get this
    "This host/domain override combination already exists with an IPv6 address."

    Your other address is coming from the transparent lookup?



  • Without any local host overrides, I declared and alias "SYS_URL" with some URLs :

    34e50b9a-b3ac-4767-872b-fbbcc76333dd-image.png

    One of them has only an IPv4 - the others have both IPv4 and an IPv6.

    After validating the table, I checked right away :

    26900ea7-4921-4e5b-8fb5-7b0d60751c3a-image.png

    witch is all correct.


  • LAYER 8 Global Moderator

    I think maybe he is creating host override for specific fqdn, and then expecting it to also pull other addresses for that same fqdn from the public dns?

    Not sure what his issue is, but from my understanding of that redmine - its very specific to specific sorts of setups.. I have never seen it on my systems.



  • @Gertjan said in Firewall Alias not updating table correctly:

    Without any local host overrides, I declared and alias "SYS_URL" with some URLs :

    34e50b9a-b3ac-4767-872b-fbbcc76333dd-image.png

    One of them has only an IPv4 - the others have both IPv4 and an IPv6.

    After validating the table, I checked right away :

    26900ea7-4921-4e5b-8fb5-7b0d60751c3a-image.png

    witch is all correct.

    You have it. Except my router is not behaving that way all the time. I have one alias that behaves exactly like yours, and another that I described in the initial post, and it isn't putting all the IP addresses into the table.

    Responding to some of the other comments:

    First, I don't use host overrides. From my original post: "For background, I am using DNS Resolver and there is a domain override in place for myDomain.com (TypeTransparent). It's working as expected."

    Second, I am not using public DNS for this. There is a public DNS server for the MyDomain.com zone.
    However my router does not forward DNS queries and the public DNS server has no entries for myHost.myDomain.com.

    Third, the mydomain.com override points to a Windows AD server. I bring this up because it may be precipitating the issue. nslookup against both servers return the same results for myHost.myDomain.com. However resolving my Aliases into tables is not storing the same results into the table. In fact at the time of this writing, the table is empty.

    Fourth, to be exact, I am testing the feasibility of creating private social networks using secure peer-to-peer communications. Residential service must be accommodated yet, for no good reason, most ISPs are issuing IPv6 network addressees that change. I can use dynamic DNS to communicate address changes to peers. However if I am to support this firewall I need a way to alter firewall rules when peer addresses change. In other words, I need to be able to let them in. Aliases seem like the only way to go.

    So, here is how I see it now, based on input received so far:

    1: This is a bug that occurs when Aliases are being resolved because it's doing its own thing and processing something other than what nslookup would return. After all I am comparing the results of an nslookup to the contents of the table and they are different.

    2: It's a bug and the alias resolution process is receiving the correct list of records but is choosing, correctly or incorrectly to filter some of them out.

    3: I am misunderstanding the documentation (it wouldn't be the first time, but it's rare). The documentation is vague when it comes to use-cases in this regard.

    4: The documentation is missing a constraint we need to know about.

    5: I missed something in the documentation (this occasionally occurs)

    Right now I am inclined to go with number 1. I have been trying to determine if this is something that will will be addressed by bug #9296 , or if I need to open a new bug report. If it's not a bug then it'll become a feature request and I'll have to go another way.

    @Gertran did you auto-add your alias? The timestamp entries lead me to believe that. If you did, can you tell me what button you pushed to make that happen?


Log in to reply