Internal DNS Not Working
-
Here are the traceroutes to the hostnames of the DNS servers which are specified in the general setup page. Traceroutes fail if I attempt any other hostnames. In general setup, for this to work I need to set both gateways to use the DNS pair from the same provider, otherwise the opposing WAN and LAN wont be able to reach. Below I used 1.0.0.1 on WAN2 an 1.1.1.1 on WAN1.
When DNS servers from different providers are in General Setup, I can ping both IPs from any interface, but I can not traceroute to both hostnames, only the IPs.
-
@aiden21c I suggest using the DNS lookup diag page to test DNS problems. While Google DNS should answer pings, testing by ping introduces another layer. One problem at a time . :)
Re pinging DNS servers, I believe pfSense sets up routing entries for them specifically. Ensure you have a default route and/or routing is correct.
-
@steveits as is visible above, DNS lookup was actually working. I was able to lookup facebook.com and have repeatedly been able to lookup google.com and others. I think this is likely a firewall or NAT issue, or something else entirely.
I still can't get my head around why my LAN client is able to use pfSense as it's dns and everything works fine, but the pfsense itself is having DNS (and outgoing Ping) issues, as I'm not actually able to use the ping diag tool to ping any IPs other than those specified. -
My turn.
I left "Resolving mode" for 48 hours.
I've tested Forwarding for a while.I chose "1.1.1.1" - so I went to to 1.1.1.1 set up instructions. I even added TLS support.
So : first :
Take note : strictly speaking, I have just one WAN, but IPv4 and IPv6 are separate. Half of all my outgoing traffic is IPv6 these days.
Then : Unbound :
I made no changes to the Unbound Advanced page, neither the ACL page.
I have no floating rules.
A DNS NAT rule for a specific interface : I force the (captive) PORTAL network to use 127.0.0.1 : that's unbound. I might as will delete this rule, I'm not using it myself.
And that's it.
This morning, I even forgot about the fact I was not resolving anymore.Since the day before, unbound didn't restart.
No DNS interruptions as far as I know.
During breakfast this morning, no captive portal clients were complaining.Btw : I'm using 23.01.
I've done an identical test during one week with 22.05
Same thing with 2.6.0, the CE version.
Using a SG-4100.
I was using VDSL before January, 15, 2023. Since then, fiber.No "help me" PM's please. Use the forum, the community will thank you.
Edit : and where are the logs ?? -
@gertjan @aiden21c Please remove all port forwards or firewall rules that redirect or block DNS. If you have such rules activated with recursive mode, you are essentially redirecting Unbound packets back to itself.
@Gertjan Happy it works, anyway. Sorry for the edits, rushed to answer without drinking my coffee, first
. -
@gertjan I must confess I don't have your full network diagram, though. If you get a chance, just to help anyone researching this in the future, make us a mock-up.
-
@aiden21c Show screenshots of your firewall rules (all of them, and remove any public IPv4's), all Port Forwards and your Gateways (System->Routing).
-
@gertjan Perhaps you were missing the accompanying FW rule?
-
@nightlyshark These are my current firewall rules. I am not nearby the device atm, however I dont understand how removing the IPv4 route rules will help with this. I have no firewall rules on WAN1 and on WAN2 i only have the default rule which is added by the OVPN server. I have tried moving the DNS rule from the bottom to the top of the list to no avail.
I have no port forwards at this stage. I have a static route to 10.118.32.0/20 via the 192.168.6.0/30 network.
I have tried this configuration with and without any DNS listed in General Setup.
I have 2 gateways with no "Default IPv4" or "Default IPv6" gateway set.
WAN1 - 192.168.6.1/30
WAN2 - 192.168.20.1/24
Let me know if you require any more info. -
@aiden21c The counters for your first 2 rules show no traffic, just pointing it out.
When I asked about the FW rules, I meant (mostly) Floating, WAN and WAN2. -
@aiden21c If you have private IPs on WAN and WAN2, that means that PfSense is behind a NAT. Routers should not (generally) connect to each other via the private space or behind NAT.
-
@nightlyshark I don't have any fw rules on either Wan interface, nor any floating rules. I believe this is the issue I'm having where I have a double NAT on each interface. As per my network diagram above I do have routers on both WANs which are acting as a gateway for the pfsense. How would I go about avoiding this issue as I don't really have any other option for my setup.
-
@aiden21c said in Internal DNS Not Working:
I dont understand how removing the IPv4 route rules
Your NZ_Office rule is before the others (including DNS) and covers everything, making those rules unusable. The more general rules (any->any) go after any rules with restrictions (443, 80, 53).
Also, your second rule has a destination of 192.168.6.1/30. Is this correct? Maybe you meant 192.168.6.0/30?
Also, also, you have two routing rules for WAN, but a single gateway. Each WAN that routes somewhere should get a gateway.
Also, also, also you have a routing rule for a private IPv4, 10.118.32.0/20:
Is that the office subnet? I didn't see an interface on PfSense with an address in that subnet. -
@aiden21c Do you mean CPE routers when you say "routers"? If so, you must contact your ISP(s) and get them to activate PPPoE passthrough on their CPEs, in order for you to be able to connect with a public IPv4.
-
This is how I'm set up:
-
@aiden21c If you don't have administrative access to those routers, your only option (to sneak your network) would be using a VPN. If you have administrative access on the routers and they are DSL and FTTH, turn PPPoE passthrough on on the CPE modem (call your ISP's tech support) and use a switch where you connect the PON, PfSense WAN and CPE of the FTTH ISP. The FTTH ISP would have to remove ACL MAC restrictions on your line and give you 2 dynamic IPv4s, a CG-NATed one for the CPE (telephony, TV...) and a no NAT one for PfSense.
-
That way, you also get IPv6 prefixes. (Provided your ISPs support IPv6)
-
@nightlyshark I'm not going to lie, I think I understood about half of what you have said. I do have administrative access to the office router via the site IT team, who has been more than happy to enable anything for me on the site.
The 10.118.32.0 network is my mesh Sim network I am attempting to give my OpenVPN clients. access to. I do not require any IPv6 networking, or any DHCP on the LAN of my pfsense.
I am struggling a little bit to understand exactly what you mean by the solution, but basically in the office the IT team has installed a basic cisco router setup which connects to the ISP. I believe this would be the CPE. I can get PPPoE enabled on this router which might help with my situation.
Im bit unsure what you mean when you talk about the PON and such, but basically how I have it currently setup is just one singular link from the office router to the pfsense box's wan, as the pfsense is located in an office away from the main network rack. Are you talking about a managed or unmanaged switch in the case you mentioned above? -
@aiden21c No,
- CPE is Customer Premises Equipment, it is the "router" ISPs give to domestic and small professional clients
- PON is the small box that turns fiber to ethernet (if you don't connect a device directly to fiber)
- FTTH is Fiber To The Home (meaning, no DSL)
- PPPoE passthrough is being able to connect PfSense like a CPE does (PPPoE) through the CPE itself (used on DSL, where you must either do that, or have a separate DSL modem and lose telephony)
- ACL MAC restrictions is the ISP only allowing their routers (CPE) to connect directly to the internet by blocking other MAC addresses
- CG-NAT is Carrier-Grade Network Address Translation, the "solution" ISPs have for the depletion of IPv4s, ie grouping whole buildings or even neighborhoods and passing them through a single public IPv4/32 (it's cheaper for them, less allocated public addresses)
Your IT team should have made quick work of this. Have them review the situation. Perhaps, in your case, you cannot even use PfSense and all you need (besides setting up VPN and subnetting/VLANs on the Cisco routers) is a Managed Layer 2 switch, in order to distribute the VLANs to your LAN devices.
The switch I proposed was an unmanaged one, just to get both the ISP equipment that has telephony and such and PfSense to be able to "talk" to the ISP PPP server over the fiber ethernet connection (Point to Point Over Ethernet - PfSense to ISP, CPE to ISP). That was proposed in order to both connect PfSense and not lose any telephony (VoIP) or TV you might be getting from the fiber ISP.
I will whip up a diagram.
-
@nightlyshark said in Internal DNS Not Working:
@gertjan I must confess I don't have your full network diagram, though. If you get a chance, just to help anyone researching this in the future, make us a mock-up.
Something like this :
{The Internet} <=> {My ISP} <=> fiber <=> [WAN pfSense] //pfSense// ( 3 LAN interfaces with dumb devices)
So, nothing special. Fully compliant to the rule : "keep it simple".
@nightlyshark said in Internal DNS Not Working:
Perhaps you were missing the accompanying FW rule?
I showed a NAT rule.
It's a safety net for my captive portal users, based on the pfSense official documentation :
https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html
It's not mandatory, and has nothing to do with forwarding/resolving.I just wanted to show-case forwarding => it works for me.
( and Resolving : far better ;) )No "help me" PM's please. Use the forum, the community will thank you.
Edit : and where are the logs ??
