Regression #15051
closed
Host(s) Aliases using Domains fail to resolve
0%
Description
A very similar issue to this bug which has already been resolved: https://redmine.pfsense.org/issues/14947 which regarded Aliases for URL. This bug applies to Host(s).
IP addresses in an Alias marked as Type: Host(s) still work, but domain names placed in there do not. They just are ignored or not resolved, I've not found any errors related to it like the above bug I linked to in the pfSense logs, it appears to just ignore the domains or silently fail to resolve them.
This issue does not exist in the prior 23.05.1 and is also not resolved by installing all the available patches for 23.09 including the patch noted above for the similar Alias bug I linked to.
Files
Updated by Danilo Zrenjanin over 1 year ago
- File clipboard-202401251511-xgq7o.png clipboard-202401251511-xgq7o.png added
- File clipboard-202401251512-adnj5.png clipboard-202401251512-adnj5.png added
I couldn't confirm that behavior on the 23.09.1 pfSense Plus release.
Please see the screenshots below:
Updated by John Smith over 1 year ago
Danilo Zrenjanin wrote in #note-1:
I couldn't confirm that behavior on the 23.09.1 pfSense Plus release.
Hey Danilo, thank you for checking this bug. I should have clarified something, I did not know this diagnostic page you just posted existed. The issue I encountered was when I wanted to route specific clients through specific VPN tunnels based on hosts in an Alias it did not work.
Aka example.com in an alias, all clients going to example.com should be diverted from WAN to OpenVPN for that domain, still accessing it via WAN instead.
So I assumed the domains were not being resolved but perhaps the bug is elsewhere? - If you can check this in some way I would appreciate it and I apologise for not knowing about the diagnostic tables page or I would have been more specific with my bug report.
Updated by Marcos M over 1 year ago
- Project changed from pfSense Plus to pfSense
- Category changed from Aliases / Tables to Aliases / Tables
- Status changed from New to Not a Bug
- Affected Plus Version deleted (
23.09)
Aka google.com in an alias, all clients going to google.com should be diverted from WAN to OpenVPN for that domain, still accessing it via WAN instead.
This won't work due to the use of CDNs and many different sub/domains used to access the service. For something like that, it's better to use e.g. the ASN.
Updated by John Smith over 1 year ago
Marcos M wrote in #note-3:
Aka google.com in an alias, all clients going to google.com should be diverted from WAN to OpenVPN for that domain, still accessing it via WAN instead.
This won't work due to the use of CDNs and many different sub/domains used to access the service. For something like that, it's better to use e.g. the ASN.
Hi Marcus,
I only picked google.com as an example domain, it's not the actual domain I'm trying to divert. I'm using domains that only have a single IP and it works every time for all of them but only on the older pfSense release and not the latest.
It's working on 10+ domains in the old release, broken instantaneously with new release, all hostnames/ips' in the alias table are ignored by the firewall rule as if they do not exist. I can literally reboot the firewall into the old release using the snapshot feature and it works, go back to the new release, broken etc
So if someone wants to pick a domain they know only has a few IP's etc - try that.
Updated by Marcos M over 1 year ago
- Status changed from Not a Bug to Incomplete
It may be best to troubleshoot/discuss further on the forums to narrow down the issue given that we cannot reproduce it.
Updated by John Smith over 1 year ago
Marcos M wrote in #note-5:
It may be best to troubleshoot/discuss further on the forums to narrow down the issue given that we cannot reproduce it.
Dear Marcus,
Have you tested it though? as the issue isn't that the IP's don't show in the Alias table, it's that the firewall does not react to them and route traffic based on what is in the alias table.
Updated by Steve Wheeler over 1 year ago
- Tracker changed from Bug to Regression
- Status changed from Incomplete to Not a Bug
Unable to replicate that in 23.09.1:
steve@steve-NUC9i9QNX:~$ ping atxfiles.netgate.com PING files.atx.netgate.com (208.123.73.81) 56(84) bytes of data. 64 bytes from atxfiles.pfsense.org (208.123.73.81): icmp_seq=1 ttl=61 time=122 ms 64 bytes from atxfiles.pfsense.org (208.123.73.81): icmp_seq=2 ttl=61 time=122 ms 64 bytes from atxfiles.pfsense.org (208.123.73.81): icmp_seq=3 ttl=61 time=122 ms ^C --- files.atx.netgate.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 121.873/122.014/122.168/0.120 ms
[23.09.1-RELEASE][admin@fw1.stevew.lan]/root: pfctl -vvss | grep -A 3 208.123.73.81 all icmp 208.123.73.81:6 <- 172.21.16.8:6 0:0 age 00:00:04, expires in 00:00:09, 4:4 pkts, 336:336 bytes, rule 144, log id: 89a6ce6500000000 creatorid: 92ac4dc8 route-to: 172.27.114.129@ovpnc1 origif: mvneta0 all icmp 172.27.114.158:65236 (172.21.16.8:6) -> 208.123.73.81:65236 0:0 age 00:00:04, expires in 00:00:09, 4:4 pkts, 336:336 bytes, rule 125, allow-opts, log id: 8aa6ce6500000000 creatorid: 92ac4dc8 route-to: 172.27.114.129@ovpnc1 origif: ovpnc1
[23.09.1-RELEASE][admin@fw1.stevew.lan]/root: pfctl -vvsr | grep @144 @144 pass in quick on mvneta0 route-to (ovpnc1 172.27.114.129) inet from <Workstations:8> to <Test_FQDNs:2> flags S/SA keep state label "USER_RULE: Route access to Test via Netgate" label "id:1706541134" label "gw:OPT4_VPNV4" ridentifier 1706541134
[23.09.1-RELEASE][admin@fw1.stevew.lan]/root: pfctl -t Test_FQDNs -T show 208.123.73.81 2610:160:11:11::81
Table is populated as expected. Policy routing rule matches and routes the traffic as expected.
Tested:
23.09.1-RELEASE (arm) built on Wed Dec 6 20:22:00 GMT 2023 FreeBSD 14.0-CURRENT
Updated by John Smith over 1 year ago
Steve Wheeler wrote in #note-7:
Unable to replicate that in 23.09.1:
Thank you Steve, I have reinstalled 23.09.1 and I too am unable to replicate the bug that I first reported here. I apologise for wasting everyone's time I can only assume the issue I experienced was caused by something else which I cannot replicate now.
If I face issues in the future I will make a forum post before I create a bug report to not waste the developer's time. Thanks!