Adding a Subnet to an Interface
-
@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.
-
@nogosubnet BTW - as I mentioned I wouldn't use /29 in your wan rules.. Since this allows access to the web gui on pfsense opt1 interface from the internet..
I am able to hit your webgui via public internet on the .25 address. Your wan rules should be set to only allow access to the ports and IPs you want to allow access too. I doubt you want people to be able to hit the pfsense web gui from the internet. They would only need to guess the password to get in.
