Adding a Subnet to an Interface
-
@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.
-
@johnpoz To be honest I am having a hell of a time trying to set the firewall rules for LAN: set to allow anything they work (understandable enough), but as soon as I try to lock them down they fail and totally block all internet access for LAN browsing.
I have tried resetting the states (did not work) and I tried every combination I can think of as far as rule format is concerned (including IPv4 and TCP only), nothing works: I either have fully open everything or nothing. - Heck, even if I just change Any to TCP on a rule, it blocks all internet access!!!
I did try copying the HTTP and HTTPS rules from OPT1; but as I do not browse the internet via the webserver I am unable to say whether they are, too, are actually working or not (they certainly do not work for LAN!). They do work, though, - provided I keep the Cloudflare DNS entries in resolv.conf: 127.0.0.1 is necessary for the DNS resolution, but the Cloudflare entries are being used for HTTP and HTTPS (so only port 53 activity is being passed to the pfSense side, port 80 and port 443 is being handled by Apache, I guess, that being the HTTPD daemon on the server); so thanks for making me aware of that, even though it looks as though I need to retain all the entries.
As for the other, non-in<snipped>.info sites, do not worry about them: they not intended to be publicly visible at the moment.
-
@nogosubnet said in Adding a Subnet to an Interface:
but as soon as I try to lock them down they fail and totally block all internet access for LAN browsing.
Well lets see the rules.. If your going to lock down, don't forget to allow for dns.
Min rules you would need to allow for if your going to lock to 80/443 for web traffic is dns. To where your client is pointing to for dns.. Or no your not going to be able to go anywhere.
Keep in mind rules are evaluated top down, first rule to trigger wins, no other rules are evaluated.. So if your going to put in any block rules, you need to make sure your allow rules are above any block rules you might put in. Keep in mind by default, if not allowed then its blocked by default.
Common mistake I see is not allowing for dns. Can't look up where you want to go, if you do not allow for dns.
provided I keep the Cloudflare DNS entries in resolv.conf: 127.0.0.1 is necessary for the DNS resolution, but the Cloudflare entries are being used for HTTP and HTTPS
Just wrong - plan and simple.. DNS is DNS on port 53 - there is nothing being looked up via cloudflare for name resolution via http or https.. Now you might be able to setup doh or dot to do dns over https or 853 via tls. But you could have to make sure you dns client/resolver/forward is setup to do that - and just those ips in resolv.conf sure and the hell would not work for that.
What would be the point of asking cloudflare to resolve your domains - since your authoritative name servers are on your own network.. Why should you ask them, just for them to come back and ask your own name servers. Just have your webserver ask your local bind.. Make zero sense to forward to anywhere on the public internet to ask for what the ips are for your records - since your authoritative name server are right there on your own network.
-
@johnpoz Well these are the OPT1 rules ...and I would have expected them to be similar, only with no need for WAN rule additions (although I have tried adding LAN rules to the WAN interface in addition to LAN) and it made no difference (even after resetting the States):
...and these are the LAN rules based on the above (following the addition of a DNS rule, as per your advice):
Unfortunately, the only thing that actually works (regardless of whether States reset or not) is the following:
Yes, I know: not at all what I want to be doing...
Thanks, too, for the following:
"@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."
I will remove those rules shortly and see what happens (preferably after I have managed to get some more of the rules actually working, that is.
-
Everything is now absolutely perfect, save for a stuttery SSh connection (for some reason the connection is inconsistent and it frequently takes several attempts to connect) which often freezes. This has probably got a lot to do with the hardware configuration, though, and the additional processing overheads as a result of the pfSense arrangement; but I remain hopeful that the returns from such an arrangement will outweigh that in time.
...so, again, thanks to everyone who has helped me get this working, - your input was really appreciated, as was your determination to tame my pfSense.
-
@nogosubnet Well the rules you posted woudn't work because you have lan set to lan net for destination. How would that allow access to the internet..
Those rules say anything (already on the lan net - so really only source could be lan net) But your saying you can go to the lan net - which they are already on.. How would that work trying to go to say 8.8.8.8 or 1.1.1.1 - ie the internet.
Source should be lan net, and destination should be ANY..
additional processing overheads
No that has zero to do with anything.. Since you have not actually given any details on how you actually have the lan side infrastructure setup - if I had to guess I would guess asymmetrical traffic flow.. You have 2 networks - how do you have them isolated? You have 2 physical switches, you have a vlan capable switch?
And the opt1 rules you posted same problem - you list your dest as opt1 net.. Again how would that would work as destination, from the opt net..
edit: BTW you say its working - but I can not query your dns from internet again, nor does the apache site come up even.
-
After one hell of a fight I finally got the rules working:
My website was down last night, - no idea what happened, - network connectivity literally just died and stopped responding, and could only be restored by restarting the machine. This is not the first time that has happened, and I have no idea what causes it or why it happens, but I do know that it sometimes coincides with heavy and sustained network attacks (although I would have thought that the networking would resume afterwards, bearing in mind that the underlying services are, in all cases, still working and showing no errors).
I am also seeing a lot of flakiness with pfSense: very slow, unstable, connections, erratic SSh connectivity, and seriously poor connectivity (especially with the webserver), but I am hoping that improvements in the cabling and hardware might mitigate some of these problems.
There is also an issue with rule ordering, which I am stuggling to find information on; specifically, do the block rules go at the top (as I suspect), and what sort of impact will they have on rules that proceed them? - One of my rules is an inverse (!LAN) rule on the OPT1 tab to prevent access to a port from everything save the LAN subnet, but should that rule be at the top, and will the blocked port apply to every rule (including pass rules) underneath it?
...and, yes, there is a missing port number from the above: this detail was deliberately removed prior to posting.
-
@nogosubnet your site is down now.. I can query your dns, but not access apache.
Rules are evaluated as traffic enters the interface, top down, first rule to trigger wins, no other rules are evaluated..
Pretty much like very other single firewall on the planet..
-
@johnpoz ...so "first rule to trigger wins, no other rules are evaluated" as in the first rule concerning a given protocol, port, etc., meaning that any other similar situation (same protocol, port, etc. in a later rule) would be disregarded? - Fair enough, - thanks.
The website was back up a few minutes ago, - I have no idea why the availability of that site is being such a basket because, outside of the pfSense arrangement, there are seldom any issues ...so it could be board issue, ethernet cable issue, or possibly the network card (I do not feel that it is a configuration issue because the configuration is the absolutely minimal required to make it work and to lock it down). I have made some changes and will be replacing the ethernet cables to fully shielded 5e cables to eliminate them as a problem, and will just have to take things from there.
-
@nogosubnet If the rule matches be it block, be it allow - no other rules would be looked at.
So for example if you had a rule that blocked anything to port 456, and the other setting on the rule allowed for a match of your traffic to 456, like source and dest ip... Then no a rule below that said hey any any would not be evaluated.
Its pretty simple start from the top walk down your rules - what rule matches.. There you go - no need to look at any other rules.
edit: site still down... I don't know how your testing - but its not available from teh public internet. Dns working - but nothing answers, no apache.. nothing when go to IP or fqdn.. even those the fqdn resolve.
-
@johnpoz Fair enough, - thanks.
The problem with the webserver connections being forcibly killed is definitely a pfSense issue: I do not know what is happening, and have no way of tracing it, but there is definitely something on the pfSense side of things that is blocking (and actively killing) connectivity with the webserver.
I have also tried to implement the DNS ANY fix and can confirm that it does not work in BIND, as BIND does not recognize the records as being valid syntax and, quite honestly, even the hacker groups do not recognize the 'fix' so, yes, it may look good but, outside of that, it would unfortunately appear to be nothing but another cute piece of theory.
As an example of what is happening on the connectivity side of things, pfSense will often show OPT1 as being down when it is not and SSh connections will immediately freeze and die upon opening ...or everything will be running fine on the webserver but it will be impossible to view the website or to connect via SSh (connection to one of the web addresses), - indicating a possible issue with the HTTP or HTTPS rules even though both are fine.
-
@nogosubnet said in Adding a Subnet to an Interface:
The problem with the webserver connections being forcibly killed is definitely a pfSense issue
Says who? Do you have logs of this? Who says anything is being killed? Maybe your internet connection just blows? Why don't you open up your wan IP so can ping that at least. And can validate if can even get to pfsense. Pfsense can not allow traffic it never sees, etc.
Your dns is not working currently either.
BIND does not recognize the records as being valid syntax
Zero idea what your talking about.. Support for this was added back in bind 9.11
https://www.isc.org/blogs/bind-release-911/Minimal Response to ANY Queries
Queries for ANY records are a possible abuse mechanism because they typically extract a response much larger than the query.
The new minimal-any option reduces the size of answers to UDP queries for type ANY by implementing one of the strategies in “draft-ietf-dnsop-refuse-any”: returning a single arbitrarily-selected RRset that matches the query name rather than returning all of the matching RRsets.
minimal-responses takes two arguments: no-auth suppresses populating the authority section but not the additional section; no-auth-recursive does the same but only when answering recursive queries.
pfSense will often show OPT1 as being down
Well if pfsense says the interface is down, then its down to pfsense for some reason - if that is the case then yeah your going to have issue.. Again you have not given any insight at all to how you have any of this connected together. So nobody can help you.
