Adding a Subnet to an Interface
-
What your trying to do is 2 minutes of configuration - tops! I am sorry you are confused on how any of this works..
What are you wan rules?? That is 10 seconds for you to do - but you can't seem to be bothered.
-
@johnpoz yes, I realise that, and no need to apologise; but I simply cannot make sense of what is required: I read the articles, find something that should work, try it, try something else, something else, and nothing gives ...whilst the articles just suggest progressively more hellish configurations, none of which work, either.
Then, just to really take the piss, I find that rules that should allow completely open, unrestricted, access for various services don't ...so I cannot be sure that I have eliminated various potential solutions even when I think I have (and that holds true with all the interfaces, not just that that I am working with!).
I have also identified the problem that needs addressing (that of being able to resolve DNS queries and access to the webserver BIND DNS resolver, ie: the /29 BIND DNS resolver needs to be able to access the internet or, at the very least, pfSense's resolver) but I simply cannot find any way of resolving it. I did investigate Host and Domain options under the DNS Resolver configuration (as suggested by @SteveITS), but that did not fix the problem, either.
...so you can see why this, to me, appears to be an excercise in completely futility.
-
You need a firewall rule that allows udp/tcp port 53 on your wan to the /29 IPs address bind is running on..It is that simple. And the box your running bind on needs to have gateway set pointing back to pfsense opt1 address x.x.x.25?? In your /29
So again I ask - post up your wan rules.. There should be no port forwards.. Lets see your outbound nat rules..
What pfsense has set for dns, has nothing to do with bind talking to the internet, or the internet talking to bind...
It was working for a bit - since I was able to query your bind servers. Maybe you had a any any rule on your wan? You didn't put back that nonsense port forward of ports 1-65k to the opt address??
Let me guess - you have 1 box.. Your webserver.. You don't actually have another box on x.x.x.26 and .27 and .28 and .29 running bind do you. What is registered for your domain name servers is .28 and .29 -- but then when you ask your name servers for ns1 or ns2 it says that ns1 is .26 and .28, and ns2 is .27 and .29
You currently have it working - as I am able to query to the .28 address
I can query all 4 of the IPs .26-29 and get a response..
When I go to other domain.info your also setup for I can get to that site
But your primary domain.uk I just get the apache page. Both present a acme cert with san for both domains. So your problem currently is with your apache setup and host headers displaying the correct site..
I have blocked out your domain names, for your privacy - but all of this info is available from the IPs you posted via a bit of simple detective work.. So you might want to remove your IP range you posted. Or I can remove/edit it you wish? Or we can stop hiding your domain names and make it easier to discuss.
edit: also seems you have .30 running bind as well - since I can query that as well - and apache loads on that IP as well.
edit2: looks like glue is ok and ns are only returning the .28 and .29 addresses, but you have bind listening on all the ips .26-.30 as well as apache.
edit3: While your bind is not allowing for open resolving which is good.. It is answering a query for ANY.. This has been deprecated many years ago.. And get back all the records.. I would really suggest you disable answering a ANY query..
You can get info about not answering any with every record here
https://datatracker.ietf.org/doc/html/rfc8482Here is a good blog post about it
https://blog.cloudflare.com/rfc8482-saying-goodbye-to-any/ -
@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!
