Project

General

Profile

Actions

Bug #5806

closed

Alias URL table containing an unresolvable FQDN entry causes rules to not load

Added by robi robi over 8 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Aliases / Tables
Target version:
-
Start date:
01/23/2016
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:

Description

Set up an URL alias pointing to an internal http resource, listing about 25 entries, each a public FQDN.
Set up a port forward on the WAN interfaces, specifying as source the URL alias.
If for some reason one of the FQDN entries in the list becomes unresolvable (for example pinging it from command line gives back "ping: cannot resolve example.com: unknown host"), the whole firewall breaks.
No more NAT through pfSense (I can ping google.com from pfSense box, but cannot ping it from any network behind it). There are alerts in the web interface complaining that the file containing the list in /var/db/aliastables/ is invalid, these get also registered in the system log.
Routing without NAT seems to work between local interfaces, but I couldn't access remote sites through VPN, which are NATted on their virtual interfaces.

This happens on a C2758 system, with amd64 architecture NanoBSD.

Temporary solution (outside pfSense) was to add FQDN > IP translation and validation on the internal server (using php gethostbyname() and ip2long()), so that the URL alias always gets existing IP addresses and not FQDNs, which may be unresolvable.

A fix on pfSense would be when an URL alias contains names, skip the ones not resolving, and not try to add to the table.

Actions #1

Updated by robi robi over 8 years ago

Happened on v2.2.6, and reproduced on v2.2.4 too, but with a different error in the system log.
Removing the problematic FQDN address from the list doesn't fix it, the table gets created, but traffic still doesn't get through.

The only remedy is to reboot.

Unfortunately can't quote the exact errors from the log, because they are not saved on NanoBSD.

Actions #2

Updated by Chris Buechler about 8 years ago

  • Category set to Operating System
  • Status changed from New to Confirmed
  • Priority changed from High to Normal
  • Affected Version set to All

You end up with a syntax error that prevents loading of the ruleset in that case.

no IP address found for google.com
/tmp/rules.debug:29: file "/var/db/aliastables/test.txt" contains bad data

Putting the FQDNs directly into a host alias won't do that since filterdns handles the name resolution and table manipulation then.

Actions #3

Updated by robi robi about 8 years ago

Yes, that's exactly the error mesage I was seeing. Thank you.

Actions #4

Updated by Chris Buechler almost 8 years ago

  • Subject changed from Alias URL table containing an unresolvable FQDN entry breaks the whole firewall to Alias URL table containing an unresolvable FQDN entry causes rules to not load
  • Category changed from Operating System to Rules / NAT
Actions #5

Updated by Jim Pingle over 4 years ago

  • Category changed from Rules / NAT to Aliases / Tables
Actions #6

Updated by Viktor Gurov about 4 years ago

  • Status changed from Confirmed to Closed

no such issue on 2.4.5 and 2.5.0.a.20200324.1145
it ignores unresolved hosts, putting only valid IPs in /var/db/aliastables/test.txt

Actions

Also available in: Atom PDF