Adding a Subnet to an Interface
-
@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.
-
@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.
