MultiWAN DNS and rejecting issue on OPT1
great … 10 minutes of writing gone, great forum ... writing it all again ...
WAN = DEFAULT = DNS 188.8.131.52 = direct login [ADSL]
OPT1 = specific = DNS 184.108.40.206 = Router is gateway [LTE]
DNS Forwarder > ENABLED
Register DHCP static mappings in DNS forwarder > ENABLED
Query DNS servers sequentially > ENABLED
Localhost & LAN = Gatways for DNS Forwarder
LTE Router has 220.127.116.11/18.104.22.168 as DNS and Port 80/443 forwarded to pfsense
DNS Resolver > Disabled
Back when pfBlocker was existing, there as a autocreated alias that included IP of youtube.com 22.214.171.124.
That alias was for specific IPs using WAN as internet access to be blocked on LAN tab at the firewall, so they could not access youtube.com and several other specific domains.
Now that pfBlocker is gone, I've run the script to remove everything left in the config that was left by pfBlocker
DNS Forwarder has been restarted. Firewall has been restarted. No other rules for rejecting anything related to the IPs in the alias for OPT1 usage.
pfsense gives 126.96.36.199 as IP for google.de while using 188.8.131.52/184.108.40.206 as DNS on a PC (instead of pfsense) and also ping from LTE router gives out 220.127.116.11.
I'm lost, guys. I don't know what else to do and why this problem occured and what's causing it. I really need help here and if you need more information, I'll provide it.
If I disable the rule for my PC (for ex.) to use OPT1 as gateway, so that I use WAN as gateway, I can ping 145.253.36.* and browse on google.
But when the rule is active and I am accessing internet via OPT1, I can't ping/browse that IP anymore. I could ipfconfig /flushdns on a client all the way I want.
I tried disabling DNS Forwarder and using DNS Resolver the same way but that didn't make any difference.
This configuration now was running for a year or so without any problems, but since upgrade to 2.2 (which I did just a few days ago, am usually late) it's as it is now.
Noone able to help?
I tried a rollback but that didn't work at all, even with a configuration from the same day there were suddenly pfctl command unknown issues.
So I tried a manual upgrade to 2.2.1, that was a full success. Everything was working! At first …
I pinged google.de and got 4 successful answers on 18.104.22.168
After a few minutes I tried again and ... got 4 failed on 22.214.171.124
I don't understand why.
Why does the firewall suddenly give out a different IP than just a few minutes before?
Why does the firewall block/reject that 145 IP on OPT1 but works on WAN?
There is absolutely no rule or alias or w/e leftover that would even know about this 145 google IP range.
pfsense itself can successfully ping on the 145 IP when either WAN or OPT1 is set as default gateway ...
I'm lost, I'm sad, I'm mad, out of idea and helpless at the moment ...
E: Not sure anymore if the topic is still in the right subforum. Tried to report it and have it moved to multiwan.
I pinged google.de and got 4 successful answers on 126.96.36.199
After a few minutes I tried again and … got 4 failed on 188.8.131.52
I don't understand why.
This is not Google's IP. Someone's messing up with your DNS.
inetnum: 184.108.40.206 - 220.127.116.11 netname: ARCOR-WEBCOMMERCE-NET3 descr: Arcor AG & Co descr: Alfred-Herrhausen-Allee 1 descr: D-65760 Eschborn descr: Germany country: DE admin-c: ANOC1-RIPE tech-c: ANOC1-RIPE status: ASSIGNED PA mnt-by: ARCOR-MNT source: RIPE Filtered
Suggest to use the DNS Resolver (without any forwarding) and with DNSSEC enabled…
I tried that on v 2.2 and it didn't change anything. I got the same IP and on WAN I could ping it as client and via OPT1 I couldn't.
Can't try Resolver with 2.2.1 due to
and its solution can't be used due to
error: connect: Operation timed out for 127.0.0.1
I give up, I better reinstall this whole piece of … 4h hours wasted today again, wanted to go home ... 4 hours ago.
No idea what you mean by that bug reference. That bug is fixed in 2.2.1. You have a different issue if unbound does not work for you.
None of those 145.253.36.* IPs you mentioned can be pinged, plus that's totally irrelevant, google.de should not resolve to such nonsense.
I get the same failure message by unbound, so it's the same bug to me.
We have 1x ADSL and 2x LTE (one LTE is private and not over pfsense). I get these 145 IPs on each internet access for google (not always, sometimes only for .com) and I could ping them on ADSL (pfsense WAN) and LTE private (easy box LTE but having 18.104.22.168/22.214.171.124 as DNS) but since 2.2 not on OPT1 (LTE company) anymore.
No, it's not the same bug if you see this on 2.2.1, sorry. Maybe you have screwed filesystem or something else. Definitely not the unbound 1.5.2 issue. If your user db is screwed, you indeed should do a clean reinstall.
As for the rest - dude, fix your DNS so that it does not resolve Google to bullshit. Ping is totally irrelevant. Those IPs are NOT (let me repeat - NOT) pingable. They do NOT respond to ping. That is NOT your problem.
If I would be able "to fix my DNS" I wouldn't have to open this topic to begin with.
If my ISP messes up and gives me those IPs, ok w/e if google's working [and it's been at least a year now with this IP range]. But when the pfsense does now reject access to google on OPT1 while it worked since first installation, I search a way to fix pfsense not my DNS (which I can't if my ISP has its hand on it in the end).
Christ almighty. No, pfSense does NOT reject acess to Google. There is NO Google on those BS IPs. There is pretty much nothing running on 126.96.36.199 - as you can check with some port scanner. Such as here. Ditto for 188.8.131.52.
Yes, I understood there is no google on these IPs.
But you are in no way a help. If my ISP sets these IPs / messes with my DNS even though I am using google DNS servers, then I don't care whose IPs they are.
If my ISP sets 145* to access google on my side, then I can't do anything about it.
It's always been this way and also always been this way with pfsense and multi wan. And now OPT1 gets 145 as IP for google, gives it to the client but rejects it (ok, as there is nothing but why since 2.2 and before it always worked the same it does for WAN which also gets 145).
Yes, it's not google, it's Arcor/Vodafone, my ISP - I don't care, I just want pfsense to do this what it did in the past.
Go complain to your ISP if they are hijacking your DNS… this issue has absolutely nothing to do with pfSense. OpenDNS has DNS servers on 5353, you might try those. You can specify those like
in the DNS forwarder's advanced options.
As a last resort, there are DNSCrypt servers on TCP/443.
So I deleted all DNS servers in general tab, added the line in DNS Forwarder advanced.
Restarted DNS Forwarder service, did ipconfig flushdns on client (and also booted a netbook for 2nd test fresh) and … still got 145.
The weird thing is: The Vodafone LTE router (which has google DNS server configured) gives
So I wonder if pfsense gets the 145 from WAN which is ADSL (so login at pfsense and router being bridge, while in LTE router is router and has set DNS servers) but uses it also for client queries on OPT1. (Well, idc if 145 is on WAN as there google is reachable. But if OPT1 does not do resolve via its set DNS server on OPT1 then I would need to get pfsense to not use default WAN for resolving on OPT1).
You have Outgoing Network Interfaces in DNS Resolver. Perhaps you could go and reinstall your box to get that working, no?
As I said: On 2.2 when DNS Resolver was working, I tried that already and it did not work.
btw. instead of installing dnscrypt on windows machines, I could also set google's dns servers instead of firewall, because (as was written already) that works.
I tried that already and it did not work.
You already tried WHAT?
I could also set google's dns servers instead of firewall, because (as was written already) that works.
If you call hijacked Google to be something that works, yeah, sure… have fun. I actually don't know what you are even describing, since this:
pfsense gives 184.108.40.206 as IP for google.de while using 220.127.116.11/18.104.22.168 as DNS on a PC (instead of pfsense)
makes absolutely no sense. pfSense gives NOTHING when you NOT using it at all as your DNS server on the clients.
To conclude this, your issue essentially seems to be is that you are load ballancing but the bullshit hijacked Google is NOT accessible from anywhere but from the network of the idiotic ISP who is hijacking that. So, when the traffic goes out via the sane ISP and tries to hit the hijacking idiots because it resolved to them, it gets blackholed.
I'd get rid of the moronic ISP and call it good riddance, if you ask me. Absolutely not acceptable behaviour, would not pay a cent for that.
I already tried using DNS Resolver in 2.2 with DNSSEC enabled, no forwarding, no DNS servers in general tab and using LAN/Localhost for network interfaces and WAN/OPT1 for outgoing interfaces.
But as I still got a rejected 145 I rolled back to 2.1.5 unfortunately even with a configuration restore from that date pfctl or so failed so no internet was working at all even though all gateways could be pinged in apinger.
So that's why I manually updated to 2.2.1 and have the unbound bug as stated now in the other thread.
For some reason having 22.214.171.124 as DNS on wan and as monitoring IP and having 126.96.36.199 as DNS on opt1 and as monitoring IP. I now (which I forgot before) also replaced the google servers on the monitoring IP fields with the opendns servers.
I have no idea why, but now I get 188.8.131.52 on WAN and on OPT1 YAY (I hope it's the right IP range this time).
Let's just hope it stays that way.
I want to thank you for your patience and answers, I know I can be stubborn persistent and hard to handle sometimes, especially when sitting 5 hours on a problem, being frustrated while just every man in the office expects being able to google on monday again …
So, I don't know what time it is at your zone, but it's 9pm here and I'm finally going home and I wish you a nice, uhm rest time of the day (:D).
Thank you and (for me) good night =)
Have a nice weekend. And yeah, give them a call. (None of madness this would be possible if Google signed their DNS with DNSSEC.)