Adding a Subnet to an Interface
-
@nogosubnet said in Adding a Subnet to an Interface:
but I still need to get SSh from LAN to OPT1 working.
Well that would work out of the box with the lan rules, being any any.. Even if you had no rules on opt. Just hit whatever IP is on your webserver.
If ssh is running, it would work just like you said you can hit the web page..
As stated early in this thread - does not matter what IP space used on network connected to the same router. be it rfc1918 or public.. Router will route anything that its connected to.. So unless you were policy routing specific traffic out some gateway that can not get to whatever other network is connected to pfsense.. It works out of the box as long as your firewall rules allow it.
-
@johnpoz The problem here (and I am just about to check) is likely to be that there will be no private IP advertised on the webserver side of things (ie: no address that I can use with OpenSSh in order to connect to the webserver).
-
@nogosubnet said in Adding a Subnet to an Interface:
no private IP advertised on the webserver side of things
that has ZERO to do with anything - just hit the IP that is on the webserver.. Why are you locked into this webserver needing a rfc1918 to get to it??
It has an IP connected to pfsense, and uses pfsense to route - doesn't matter what the IP space is be it rfc1918 or public.. Its just another network to pfsense.
-
@johnpoz agreed, but unless ifconfig or ip addr show gives a local address that I can connect to (ie: something specifically for the webserver) it will not allow me to connect, - even if I can otherwise ping that address, - it does not matter and the webserver will not allow me to connect. This is why I was trying to create a subnet specifically for the webserver.
-
@nogosubnet said in Adding a Subnet to an Interface:
local address that I can connect to
that would be whatever IP your public IP is you setup on this webserver - in my example 12.13.14.2
What IP does your webserver have? That is in this /29 you setup on pfsense.. That IP is the IP you would use to talk to it - be it your on some rfc1918 connected to pfsense, or some public IP out on the internet.
If you can not connect to the webservers IP 12.13.14.2 in my example - but you can ping that IP, and you can access its website on that IP. Then ssh is not running, not listening on that IP or it has a host firewall blocking access to ssh. Doesn't matter if that IP is public or rfc1918.. It doesn't!!!
-
@johnpoz Used a public IP address from the Routed IP Subnet /29 range but, no, still not SSh and webpage not being displayed (holding page only).
I am going to kill setenforce and the firewall on the webserver and see if they are the problem, because, otherwise, both httpd and sshd show no problems.
The /29 is: 87.75.210.24/29.
I have found the problem: DNS is not working or, more accurately, something is blocking it and the lookup requests on port 53.
-
@nogosubnet said in Adding a Subnet to an Interface:
DNS is not working or
Well what are you using for dns. Out of the box pfsense would hand out its IP on whatever interface dhcp is running on.
Out of the box pfsense resolves, does not forward.
What specific for dns is not working? Something your trying to resolve? Are you trying to access your webserver from public, from something on your lan? What fqdn are you using? Where did you point your webserver for dns?
You understand nothing is going to be able to get to your webserver from the public until you setup the correct wan rules to allow it.
edit: From the IPs you posted, looks like your using some of those for authoritative dns, I see PTR records saying ns1.domain.uk and ns2.domain.uk etc..
If your trying to resolve something these are authoritative for, then no its not going to work publicly if you can not get to them, etc. Your wan rules would have to all someone to talk to those IPs on udp/tcp 53
edit2: You mention webserver, but you also have NS for domain.uk that points to IPs in this /29 - so anything those are authoritative never going to work.. Unless your running those and you have edited your wan rules to allow access to those IPs.
-
@johnpoz I have updated my rules and have most things working now, - thanks, - the only issue being httpd lookups. I am not sure which ports httpd uses for its lookups, so I am looking into that now.
-
@nogosubnet httpd lookups? You mean port 80? Not sure what you mean by httpd lookups?
edit: btw I still don't show being able to talk to the ns listed in that IP space. So if those are authoritative for whatever fqdn your trying to use - its not going to work.. Atleast not publicly
Is that what you mean by "lookups"
edit2: Your dns for that domain.uk - looks jacked.. Your glue for that domain is different and you have ns1 and ns2 with 2 different addresses each, etc. Also is very BAD idea to run all authoritative in the same IP block..
-
@johnpoz Not quite, - Apache (or httpd on RHEL) does not use port 80 or 443 for address lookups, - it uses a hidden process which makes it very difficult to debug when there is a problem.
...and I have no idea what is happening with the webserver, - everything reports that everything is good (apart from httpd), but nothing is ...and nothing is getting past pfSense regardless of rules (except SSh, - which is about the only thing that is, or has).
BIND, for example, reports no problems ...but it is evident (using zonemaster.net, for example) that the report is fake and that, no, BIND definitely is not working as it should.
I cannot understand this at all: even with the webserver firewall disabled and completely open pfSense rules, the only thing that is definitely working is sshd.
-
@nogosubnet said in Adding a Subnet to an Interface:
Apache (or httpd on RHEL) does not use port 80 or 443 for address lookups
Your confused - or using the wrong terms.. Because that makes ZERO sense.. No shit 80 and 443 is not used for "address" lookups.. address lookup would be dns, which is UDP 53, sometimes tcp 53..
As I have already told you - your dns is jacked, for the domain that is set for IPs in your /29 - not going to post it on public forum for sake of your privacy. But you posted the /29 space - so anyone could look up the domain if they wanted too..
Currently nothing is going to work publically dns wise for yourdomain your running on IPs in your /29.. Because they can not be talked to from the public internet.. you have .26-.29 being listed for ns1 and ns2.. Which in itself is borked.. But can not talk to them from the public internet - did you allow for udp and tcp 53? To those IPs..
-
@nogosubnet said in Adding a Subnet to an Interface:
webpage not being displayed (holding page only).
So you're connecting successfully to the web server and just not seeing the expected content? That's not a routing issue, that's a successful connection.
For example most web servers are configured to share an IP and thus only show the site if one connects with the correct hostname. If connecting with an IP or the wrong hostname then the default page is displayed.
If you're using a hostname, is it resolving to the expected IP?
-
@johnpoz Thanks, - I know that there are issues with the DNS and cannot fix them. - I have a solution that normally works (outside of pfSense), and which reports back as good and working with Zonemaster. DNSSEC is out of the question because I can no longer get those records working with that domain and have not been able to for many months; so after much fruitless research and study I just leave the matter alone and do not bother with it.
As for pfSense, the only issue I am facing now is that of configuring the DNS bypass (I have BIND custom nameservers on the webserver and pfSense will not allow queries using those nameservers unless I make changes to System > General and Services > DNS Resolver, both of which, so far, are proving futile; although I have, at least, got internet access for the Windows PC and working firewall rules, now).
-
@steveits valid points and yes, the hostname is fine; but my DNS setup on pfSense is not: I have managed to make changes to System > General sufficient enough to allow internet access for my Windows PC, but the webserver uses custom BIND nameservers and, as I said in my reply to @johnpoz, my attempts, so far, to make pfSense allow their use have proved to be completely futile.
Basically, the /29 subnet I am using for the webserver (and only the webserver) needs to be served by the webserver's BIND DNS resolver which, in turn, would route its lookups through the same Cloudflare resolver IPs that I have set in System > General on the pfSense side of things; but getting pfSense to allow this is proving to be absolutely unworkable.
-
@nogosubnet said in Adding a Subnet to an Interface:
but the webserver uses custom BIND nameservers
And which servers are those? You list name servers only 2 names on 4 different IPs .26-.29
They resolve www.yourdomain.uk just fine before.. But now they are not again. But where are you webservers pointing too?
So you have clearly opened up wan firewall rules to allow access before. But what pfsense uses for dns has zero to do with your issue.. Where is your webserver pointing to for dns - itself?
None of these issues have anything to do with pfsense, never has.. And pfsense dns has zero to do with resolution of a domain via authoritative name servers..
-
@nogosubnet are you looking for the Host Overrides section of the DNS Resolver page?
-
@johnpoz currently I have a Hybrid NAT rule in place to remove NATting between WAN and the /29 network.
Some lookups, eg: dnf update, work, but anything involving port 443 will not, regardless of how many completely open (unrestricted) DNS and HTTPS rules I have in place.
-
@nogosubnet said in Adding a Subnet to an Interface:
but anything involving port 443 will not
What port your webserver listens on has ZERO to do with a dns lookup...
Your authoritative name servers ns1 and ns2 for your domain are currently not reachable.. So it is not possible to look up anything in that domain.
There were previous, but now they are not. So you had the rules working at one time. You are confused if you think 443 has anything to do with name resolution.. Unless you are talking about running DoH.. Which you can not to the public internet for authoritative name servers.
-
@steveits I think it could be, yes, - thanks, - but, so far, adding the /29 (or any addresses from) has not worked.
-
@nogosubnet Again - it is not going to be possible for anyone on the internet to lookup any records in your domain.. No matter what host overrides or dns setup you have on pfsense. If they can not talk to your name servers.
Allow udp/tcp 53 to the IPs running your dns .26-29 is what is listed for you domain. Which again is borked seutp.. You have 2 nameservers and their IPs listed for glue, but before when you could talk to them.. ns1 and ns2 had 2 different IPs each..
Post up your wan rules!
