Adding a Subnet to an Interface
-
@johnpoz My apologies for the late reply.
I revert the pfSense arrangement when not working on it, hence some of the problems and inconsistencies you may have been seeing.
Either way, though, thanks for the additional information, - your persistance in this matter is appreciated and I will try again to get things working, starting with the rules and further information you have asked for.
You can mention the domain if you like (it is long overdue for some major revisions, and is not the main project on my server). The BIND ANY query needs to stay: as stated by many web admins, BIND queries for public domains will not work otherwise (otherwise I would definitely have altered it). There is what looks like a possible workaround (involving placing the ANY in the zone definitions with, - presumably, - NONE as the global action) listed here:
https://serverfault.com/questions/330385/bind-would-not-work-unless-allow-query-is-any
...and I will follow-up on that once I have everything else working (along with the further linked information you provided, - thanks).
To clarify the situation with the IP addresses, x.x.x.26 and x.x.x.28 belong to NS1, whilst x.x.x.27 and x.x.x.29 belong to NS2. I cannot have less than two addresses, and trying to advertise both addresses in the zone files causes all kinds of inconsistency errors which appears to be related to there being two IPv4 addresses, as the issue does not happen when there is both an IPv4 and an IPv6 address assigned as glue to a nameserver.
For the rules, firstly the NAT arrangement (if this is wrong I may as well not worry about the rules because nothing is going to work):
WAN Rules:
The box that I am running BIND on does indeed specify x.x.x.25/29 as the gateway, - it was configured during install to only use the IP Routed Subnet /29 range of IPv4 addresses, so there should be no issues there provided that those addresses (the x.x.x.25 one, at least) map to WAN on the pfSense side of things.
What is really annoying about this is that everything on the HTTP side of things will work on startup, but will fail as soon as I restart Apache ...and I know that the problem is related to the pfSense configuration because as soon as I revert the setup back to how it was (webserver directly connected to the router, with no pfSense) the problem immediately disappears).
-
@johnpoz I will be leaving the pfSense arrangement in place until Monday in order for you to be able to check things out properly; otherwise you will seeing the alternative, non-pfSense directly-connected arrangement (which does work and which will allow you to navigate to the website).
This is an example of the command-line output when querying the status of httpd (yes, the domain names have been edited in order to obfuscate them):
Sep 26 11:30:38 localhost.localdomain systemd[1]: Starting The Apache HTTP Server... Sep 26 11:30:38 localhost.localdomain httpd[1100]: [Sun Sep 26 11:30:38.644763 2021] [core:error] [pid 1100:tid 1100] (EAI 2)Name or service not known: AH00547: Could not resolve host name some.uk -- ignoring! Sep 26 11:30:38 localhost.localdomain httpd[1100]: [Sun Sep 26 11:30:38.646452 2021] [core:error] [pid 1100:tid 1100] (EAI 2)Name or service not known: AH00547: Could not resolve host name some.info -- ignoring! Sep 26 11:30:38 localhost.localdomain httpd[1100]: [Sun Sep 26 11:30:38.990771 2021] [core:error] [pid 1100:tid 1100] (EAI 2)Name or service not known: AH00547: Could not resolve host name some.uk -- ignoring! Sep 26 11:30:38 localhost.localdomain httpd[1100]: [Sun Sep 26 11:30:38.992785 2021] [core:error] [pid 1100:tid 1100] (EAI 2)Name or service not known: AH00547: Could not resolve host name some.info -- ignoring! Sep 26 11:30:39 localhost.localdomain httpd[1100]: Server configured, listening on: port 443, port 80 Sep 26 11:30:39 localhost.localdomain systemd[1]: Started The Apache HTTP Server....and this is the content of my resolv.conf file (127.0.0.53 is auto-configured and has not been added, or edited, by myself):
nameserver 127.0.0.53 options edns0 trust-ad -
@johnpoz Further to the last post: the above details (for resolv.conf and httpd) have been added purely to give you a clearer idea of what the problem is and to show that the problem is not simply a stupid manual edit that I have made to, in this case, resolv.conf.
127.0.0.53 in resolv.conf could explain what the problem is, because surely that will simply 'resolve' to the webserver localhost? In other words any DNS lookups would go nowhere and do nothing, ie: they would be nullified. What are your thoughts on this?
-
@nogosubnet How do you think anything can work with those rules?
When would source traffic (internet trying to talk to your server) be coming from your opt1 net, ie your 87.75.210.24/29 network.. So your wan rules do not allow anyone to talk to anything from the internet.
How is your not natting rule going to work when you set to automatic.. And your not nat rule is disable..
Your resolv.conf points to your local cache that is what 127.0.0.53 is - where does that point? Prob is not your local bind install..
For starters FIX your wan rules - your not allowing anything! And your natting outbound traffic from your /29 to whatever you want IP is..
Thought you said it was ok to mention domain names - so why do you have them obsured - I know exactly what domains your trying to run.. For starters your certs have them as SAN, and its a simple lookup to find out what domains have run on any specific IP. So why are you hiding them..
Point your Webserver to your BIND server and you will be able to resolve your own domains. You can then have bind resolve or forward pfsense to local queries for stuff its not authoritative for.. When the query is from local machine.
-
@johnpoz the NAT rule is NOT Automatic, - it was configured as a Hybrid rule. - Automatic is displayed because that is the default for new rules, - it is not indicative of the selection used for pre-existing rules.
I am trying to figure out why the localhost is being set to 127.0.0.53, - this looks like a misinterpretation, with something saying localhost port 53 being interpreted as 127.0.0.53. - I will try to manually override it, preferably without having to resort to chattr, as that would fail to address the underlying issue and potentially cause further problems.
-
@nogosubnet Your nat rules are set to AUTO - look at your picture you posted, and your rule is disable - its grayed out.
127.0.0.53 points to the machines local cache.. Look it up how it works.. First google
https://unix.stackexchange.com/questions/612416/why-does-etc-resolv-conf-point-at-127-0-0-53
And your wan rule is well just borked.. How could you think opt1 would be the source of traffic coming from the internet?
The problem for starters is nobody can talk to your dns from the internet, second problem is your own webserver can not resolve its own stuff - because you don't even know where its asking for dns, if forwarding to say google.. How would google ask your nameserver for your domains - when you don't allow anything from the internet to talk to your name servers..
See here - this is how it should look. See that its not grayed out, it has a Check Mark and hybrid is checked. Using my sample public space.
That X you have your rules shows you have it disabled even if you had hybrid set.
edit: also your wan rules are going to need to allow access on 80 and 443 if you want to serve up any pages to interent. Atleast 443 if your only using https.
-
@johnpoz Funny, because I put that together using the pfSense documentation....
I will follow-up on this now, - thanks.
Now as it should be, - thanks, and my apologies for not realising that you had to save both the configuration and type once outside of the configuration.
-
@nogosubnet now your no nat looks fine - now what about your wan rules.. Still can not talk to your NS
-
resolv.conf still borked, - reading through the article you linked in your post and trying to work out what the problem is, and how to fix it (always assuming that it is on the webserver side and not that of my pfSense configuration).
-
@nogosubnet Those wan rules are NEVER going to work... Again when could your own opt1 network be the source from the internet? The internet is ANY!! Could be 12.13.14.100, or 8.8.8.8 or 1.1.1.1, any public IP could be the source.
Your rules says only allow your /29 from the internet to talk to anything - its on your own network, how would it be the source IP of traffic coming from the internet trying to talk to your IP
And also - you need to allow for the Port you webserver is going serve up on - 80/443
edit: Pretend my test net is my public space
Better yet would be to set specific IPs.. the IPs your webserver/bind is listening on vs opt1 net - since that would also include pfsense IP in opt.. Which could allow access to pfsense web gui..
-
@johnpoz fixed - thanks (I will add the 80/443 rules when, and if, I can get the underlying lookups working):
-
@nogosubnet dns now working from internet
-
@johnpoz Excellent, - thanks, - unfortunately httpd (Apache) is still unable to resolve anything.
-
@nogosubnet Well fix your webservers dns so you know where its asking... It should be just asking your local bind server.. Which would then either resolver or forward for stuff its not authoritative for..
Or if its going to ask pfsense, pfsense should have domain overrides pointing your domains to bind
-
This post is deleted! -
@nogosubnet and again - your webserver resolving something has nothing to do with pfsense.
Where did you point it? If you overwrote resolve.conf.
What I can tell you is I am able to query via you public IP and resolve your domains - ie talk to name servers that are setup for you domain via the public internet. If your webserver can not - which I assume is the same machine, or on the same network as your bind server - this has nothing to do with pfsense.
On your machine do a simple dig or host or nslookup - where is it sending its queries? Does that resolve your records? If not then no apache is prob not going to be able to resolve your stuff.
-
This post is deleted! -
This post is deleted! -
UP AND WORKING! - Thank-you so much for being so persistent with this!!
For anyone else with 127.0.0.53 nonsense in their resolv.conf:
In RHEL (Fedora) the auto-generation of resolv.conf can be prevented through resolved.conf under /etc/sysconfig (uncomment and set DNSStubListener=no), then delete the resolv.conf symlink from the /etc directory, replacing it with a non-symlinked version, and manually adding the required entries, eg:
# This file is managed by man:systemd-resolved(8). Do not edit. # # This is a dynamic resolv.conf file for connecting local clients directly to # all known uplink DNS servers. This file lists all configured search domains. # # Third party programs should typically not access this file directly, but only # through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a # different way, replace this symlink by a static file or a different symlink. # # See man:systemd-resolved.service(8) for details about the supported modes of # operation for /etc/resolv.conf. # # No DNS servers known. # nameserver 1.0.0.1 nameserver 1.1.1.1 nameserver 127.0.0.1 # options edns0 trust-adNow go to Diagnostics in the pfSense webConfigurator and click on DNS Lookup. Lookup your domain name and take note of the queried sources, one of which (at least) should be usable in the new resolv.conf.
Reboot on the Linux side and, all being well, you should now have a resolv.conf file displaying your manually entered entries and a working setup (especially if you have had @johnpoz helping you).
-
@nogosubnet Glad you finally got it sorted..
I personally would not setup my webserver to resolve like that - not when running my own local bind.
Really the only thing it should point to is itself (the loopback address).. And then bind would either resolve directly for stuff its not authoritative for or forward if you like.
edit: BTW still not able to access anything other than the default apache page for your main www.domain.uk
your www.in<snipped>.info site comes up, but not the other domain.uk one - that just serves default apache page.
