Default deny rule IPv6 (1000000105) - it's happening again!

lifespeed

@johnpoz No, I knew not to switch to the new DHCP yet, I'll leave that up to the developers when they're ready.

johnpoz

@lifespeed let me change my unbound - I currently have it set to block all AAAA

lifespeed

@johnpoz I think I can't use the same alias and same firewall rules for IPv4 and IPv6 due to the behavior of grabbing the WAN IPv4 and global IPv6. I need the LAN IPv4 and global IPv6 to successfully use a common v4/6 alias and firewall rule. It seems I can get LAN IPv4 aliasing myhost to media_server_pc, and WAN IPv4 and global IPv6 aliasing to myhost.mydomain.com.

johnpoz

@lifespeed so I just created an ailas, put in your fqdn.. And my table shows both the public IPv4 and the IPv6.

Are you wanting the rule to resolve the fqdn to your local IPv4?

how do you have unbound setup for the zone... If your using the same domain public as local - you can run into some weirdness.

If you changed the zone type to static for example something in the same zone as your using local will not be looked up.. I am not sure what would happen if you had a local IPv4 but wanted to lookup a public IPv6 in the same alias?

lifespeed

@johnpoz exactly, it would seem for an alias to be useful in firewall and NAT rules, it should point to the LAN IPv4, as with IPv4 and NAT the WAN IPv4 doesn't point to a host on the network. Should a DNS inquiry, with pfSense as my DNS server, return the LAN IPv4? If I ping myhost.mydomain.com it answers back from my LAN IPv4.

I don't know what "zone" or "unbound" are, will look.

Was the desire for this alias behavior not thought of by pfSense, and the most-correct rule/alias fix is separate firewall rules and alias' for IPv4 and IPv6?

johnpoz

@lifespeed unbound is pfsense resolver.. (dns) as to zone type it defaults to transparent, I have mine set to static - because I sure don't need it asking the public ns if I typo some local host name that is in my local domain, which I have just recently moved to home.arpa vs local.lan

https://docs.netgate.com/pfsense/en/latest/services/dns/resolver-config.html#dns-resolver-configuration

Personally I would never use the same domain locally as I am using public.. Use something else even if its your domainname with a .lan tld vs whatever your actual public tld is like .com.

It is quite easy to run into issues using a public domain that you have some records public, and some records local.. Especially if your hosting something local and would like to make sure your local stuff resolves the local IP vs the public IP, etc.

The new recommended domain to use locally is home.arpa

https://www.rfc-editor.org/rfc/rfc8375.html
Special-Use Domain 'home.arpa.'

New installs of pfsense now default to this domain.

lifespeed

@johnpoz have I made an error in naming my local domain the same as public? Not quite sure the implication of trying to correct this, and where to make the changes without borking my network. A backup config will be in order.

Will renaming my local network from the public mydomain.com to home.arpa fix the issue of using a single alias to myhost.mydomain.com that returns the unwanted WAN IPv4 and global IPv6, or will I still need to create duplicate firewall rules, IPv4 alias to myhost or myhost.home.arpa and IPv6 alias to mydomain.com.

Where in pfSense do I rename my LAN, is System/General Setup the only place? Are there ripple effects elsewhere in my network config?

lifespeed

I see I'm using DNS forwarder instead of DNS resolver, is this a problem?

lifespeed

So I switched to DNS resolver instead of DNS forwarder, static instead of transparent, per your example. Also changed my local network domain to home.arpa. None of these changes altered the awkward alias behavior.

I now have separate alias and firewall rules for my server for IPv4 LAN address and IPv6 global address. It fixed my connectivity issues, but I must say this seems inelegant. I can't see how my use case is unusual, having some servers running behind pfSense that should be accessible from the WAN both IPv4 and v6.

johnpoz

@lifespeed Still not sure understanding your problem.. The alias resolves both your public IPs

But in a port forward rule where your forwarding via a nat you would want your local IP to be allowed in the rule.. not your public.. So that would be problematic.

Creating a nat and associating a firewall rule with the local IPv4, and then changing it to IPv4 and 6 that you want to resolve seems overall inelegant if you ask me.. Create your port forward rule for your IPv4 and its firewall rule. And then create a rule to allow your IPv6 using a fqdn if you want this is cleaner way to do it. There is no nat involved with the IPv6 putting it in the same rule that is used for nat is not a optimal setup imho.

A NAT firewall rule would be pointing to the local rfc1918 address, not your public IPv4 wan address.

But if you put in the local fqdn for your local resource, ie host.home.arpa that resolves to your local IPv4 that your natting too, that should work. Here I changed my alias to have both your public fqdn, and a local record for something I might forward too.

To be honest mixing IPv4 and 6 in the same table (alias) could be problematic as well because both your wan and your gua. If I was wanting to do something like that, I would create a fqdn that only has the AAAA record, maybe use something like host.ipv6.yourdomain.com and then your local fqdn for your rfc1918 you want in your nat.

lifespeed

@johnpoz what you described is what I have done. I have NAT for IPv4, and a separate rule for IPv6. Although this doesn't seem that elegant, either.

This largely works, but the problem I'm encountering now is I would like to be able to use my FQDN to access servers from either inside my LAN or from the WAN outside from the internet at large. For most apps this works, Blue Iris, and Emby are fine connecting to myhost.mydomain.com.

However, one android client app (to Homeseer) insists on accessing the server from the LAN using myhost, while it must use myhost.mydomain.com from the WAN. It is not at all satisfactory to edit the domain to connect from inside or outside my network. It is not clear this is a firewall configuration problem, as this seems to be the only client exhibiting this problem connecting to one of several servers.

johnpoz

@lifespeed you want a local device to use your public fqdn host.yourpublic.com domain setup a host override that points host.yourpublic.com domain to whatever local IP 192.168.1.100 for example..

Now local devices resolve host.yourpublic.com fqdn to your wan IP, and your local devices using your dns would resolve it to your local rfc1918 address.

Using your public IPv4 for devices to access local resources would require nat reflection to be setup.

combining IPv4 and IPv6 rules seems nothing but problematic to me.. I would for sure keep them separate.. Might be fine if you have some rule that allows outbound to something like tcp on port 443 to anything either ipv4 or IPv6.

But using that with an alias that needs to resolve both A and AAAA for the same resource.. doesn't seem like a good idea to me.. especially if you where having both public IPv4 and local IPv4 needing to be resolved, etc.

lifespeed

@johnpoz first let me say thanks for all your help. We've established and I've implemented the following:

alias' and firewall rules , despite the option to do so, realistically can't and shouldn't combine IPv4 and IPv6. Instead use separate alias' and rules to handle NAT IPv4 as well as GUA IPv6.
The LAN domain name shouldn't be the same as the public domain name, a recommended LAN name is home.arpa.
public-facing servers at myhost.mypublicdomain.com can be accessed from LAN or WAN using firewall and NAT rules. From the LAN only, they can be resolved by pfSense DNS using myhost or myhost.home.arpa. This is an acceptable and expected result. Browser and app URL configuration can function regardless of connection to LAN or the internet at large, pointing to myhost.mypublicdomain.com.
private servers not firewalled and NAT'd are accessible only from the LAN at myhost or myhost.home.arpa, which is also expected. Remote access to these private servers, if desired, would be implemented with OpenVPN to the LAN. They were never expected to be available at myhost.mypublicdomain.com.

All that said, I do have flaky behavior from the Homeseer4 server, where the Android app can connect from the WAN using myhost.mypublicdomain.com, but fails to connect from the LAN using the same FQDN. As this behavior does not replicate with any other of the several public-facing servers on this network, I'm ascribing this to a flaky old Android app.