Thanks Jimp.

VM Superhub usually defaults to 192.168.0.0/24 subnet so your LAN subnet of 192.168.1.0/24 should not conflict. . .. so far so good. Is the SG-1000 WAN configured for DHCP ? If so then it should receive a suitable IP & Gateway from the VM Hub. Ideally you should set the SG-1000 WAN with a static IP & Gateway in the VM subnet, but outside the VM DHCP range. Although this is double-NAT it works. side benefit is that when VM updates the Superhub software it doesn't break your IP network !! If you use Modem Mode, this gets reset during Docsis software updates. VM Superhub subnet = 192.168.0.0/24 SG-1000 WAN IP Address = 192.168.0.253 /24 WAN Gateway = 192.168.0.1 (VM Superhub IP) DNS Server = VM superhub 192.168.0.1 SG-1000 LAN IP Address = 192.168.123.1 /24 DNS Resolver = Enabled (Network Interfaces = ALL) DHCP Server = 192.168.123.101 to 199 Also you need to Allow Private Networks on the WAN interface, otherwise the Superhub cannot communicate with the SG-1000 WAN.

hi, i already saw the problem, my outbound rules is set to manual and it is all directed to my first WAN. thanks for the reply guys

Agh! I can't believe I didn't bookend this thread. So sorry community! Somebody was nice enough to help me out on the Dreamhost forum here: https://discussion.dreamhost.com/t/subdomain-ddns-with-pfsense/67249/4 Essentially: you create an API key in your Dreamhost admin panel then use it as your password in the PFSense interface. Full instructions are in that link...

@kom said in Can't resolve names after blocking rfc1918: Block rfc1918 only applies to unsolicited inbound traffic, not replies to your outbound traffic. Yes, I know, that's why I don't understand why making that one changed caused this. Clients are both, can't resolve anything from any of them. I've since replaced the router with a spare I had and everything is working again. Something got screwed up in the config, kinda wish I can figure out what it is but I'll probably just reset it and see if it works again.

@lolman88 i found the solution by myself The option: "Outgoing Network Interfaces" must have "ALL" included. I only got the WANs there, but this doenst work.

@ihugof I had this problem before and since my network lease isn't huge as yours, manual (deleting expired leases) manipulation on dhcp service was my workaround.

Thanks Grimson. That's kind of same with my scenario. After reading the entire discussion, it turns out that we have different source of problem. I'll come back with DHCP info.

[image: 1540328106153-dns-resolver-advanced-settings-resized.png] Last 190 DNS Resolver Log Entries. (Maximum 190) Oct 23 21:57:20 unbound 41539:2 notice: remote address is 10.200.3.17 port 46382 Oct 23 21:57:20 unbound 41539:2 notice: sendto failed: Invalid argument Oct 23 21:57:17 unbound 41539:1 notice: remote address is 10.200.3.17 port 35019 Oct 23 21:57:17 unbound 41539:1 notice: sendto failed: Invalid argument Oct 23 21:50:47 unbound 41539:0 info: generate keytag query _ta-4a5c-4f66. NULL IN Oct 23 21:50:47 unbound 41539:2 info: generate keytag query _ta-4a5c-4f66. NULL IN Oct 23 21:50:44 unbound 41539:0 info: start of service (unbound 1.7.3). Oct 23 21:50:44 unbound 41539:0 notice: init module 1: iterator Oct 23 21:50:44 unbound 41539:0 notice: init module 0: validator Oct 23 21:50:41 unbound 71806:0 info: 32.000000 64.000000 4 Oct 23 21:50:41 unbound 71806:0 info: 16.000000 32.000000 2 Oct 23 21:50:41 unbound 71806:0 info: 8.000000 16.000000 3 Oct 23 21:50:41 unbound 71806:0 info: 2.000000 4.000000 1 Oct 23 21:50:41 unbound 71806:0 info: 0.131072 0.262144 2 Oct 23 21:50:41 unbound 71806:0 info: 0.065536 0.131072 1 Oct 23 21:50:41 unbound 71806:0 info: 0.032768 0.065536 7 Oct 23 21:50:41 unbound 71806:0 info: lower(secs) upper(secs) recursions Oct 23 21:50:41 unbound 71806:0 info: [25%]=0.0561737 median[50%]=0.262144 [75%]=24 Oct 23 21:50:41 unbound 71806:0 info: histogram of recursion processing times Oct 23 21:50:41 unbound 71806:0 info: average recursion processing time 11.680555 sec Oct 23 21:50:41 unbound 71806:0 info: server stats for thread 3: requestlist max 4 avg 1.75 exceeded 0 jostled 0 Oct 23 21:50:41 unbound 71806:0 info: server stats for thread 3: 27 queries, 7 answers from cache, 20 recursions, 0 prefetch, 0 rejected by ip ratelimiting Oct 23 21:50:41 unbound 71806:0 info: 32.000000 64.000000 1 Oct 23 21:50:41 unbound 71806:0 info: 16.000000 32.000000 8 Oct 23 21:50:41 unbound 71806:0 info: 8.000000 16.000000 5 Oct 23 21:50:41 unbound 71806:0 info: 4.000000 8.000000 3 Oct 23 21:50:41 unbound 71806:0 info: 1.000000 2.000000 1 Oct 23 21:50:41 unbound 71806:0 info: 0.524288 1.000000 1 Oct 23 21:50:41 unbound 71806:0 info: 0.262144 0.524288 2 Oct 23 21:50:41 unbound 71806:0 info: 0.131072 0.262144 5 Oct 23 21:50:41 unbound 71806:0 info: 0.065536 0.131072 4 Oct 23 21:50:41 unbound 71806:0 info: 0.032768 0.065536 3 Oct 23 21:50:41 unbound 71806:0 info: lower(secs) upper(secs) recursions Oct 23 21:50:41 unbound 71806:0 info: [25%]=0.16384 median[50%]=4.66667 [75%]=17.5 Oct 23 21:50:41 unbound 71806:0 info: histogram of recursion processing times Oct 23 21:50:41 unbound 71806:0 info: average recursion processing time 8.791496 sec Oct 23 21:50:41 unbound 71806:0 info: server stats for thread 2: requestlist max 4 avg 2.0303 exceeded 0 jostled 0 Oct 23 21:50:41 unbound 71806:0 info: server stats for thread 2: 50 queries, 17 answers from cache, 33 recursions, 0 prefetch, 0 rejected by ip ratelimiting Oct 23 21:50:41 unbound 71806:0 info: 16.000000 32.000000 2 Oct 23 21:50:41 unbound 71806:0 info: 8.000000 16.000000 3 Oct 23 21:50:41 unbound 71806:0 info: 4.000000 8.000000 1 Oct 23 21:50:41 unbound 71806:0 info: 2.000000 4.000000 1 Oct 23 21:50:41 unbound 71806:0 info: 0.262144 0.524288 1 Oct 23 21:50:41 unbound 71806:0 info: 0.131072 0.262144 3 Oct 23 21:50:41 unbound 71806:0 info: 0.065536 0.131072 5

I think it is not broken. Vodafone do not want their clients to use WiFi calling outside Germany. So the hostname epdg.epc.drz1.vodafone-ip.de is only resolved in Germany. I experienced the issue with my companies network. We were bought an american company. They switched the firewall etc to US. Ie all DNS queries were routed through US. From that time onwards WiFi calling was not working any longer. I asked them to add an exception ie the domain vodafone-ip.de should directly be queried at drz1.vodafone-ip.de Then it was working again.

I've tried asking on the IPLeak forums about what the 100 errors mean and no one has come back to me with an informative reply. Best i can figure out the errors signify that no DNS servers were found or able to be verified as leaking or not. While i can't rule out the possibility that its more an issue with IPLeak or something else, to me it seems very conclusive that the problem lies with the update to PFsense and its dns resolver feature. I've checked, double checked and triple checked that the settings I'm using in 4.4 are the same as what i use in 4.3. I've had 2 boxes running side by side, one using 4.3 and the other using 4.4. In 4.4 it fails to work and i get the 100 errors. In 4.3 it works fine and i get 1 result with no leaking detected and more importantly no errors. It's not the browser or computer i use to access the site that's the problem as they stay they same. The only thing that changes is what version of PFSense I use. I've even tried setting up PFSense to act as a router to my main internet connection so as to eliminate openvpn being an issue along with the other settings i use to make the openvpn connection work how i need it to. Putting my ISP's router into modem mode and configuring PFSense in a very basic setup to get the IP from the modem and then accessing IPLeak through this box the problem still occurs. Where as if i access IPLeak through my ISP's router without the PFSense box i get no errors and it all works fine. I understand what's been said about if it's wise to use a VPN providers testing site but it's what i've used without a problem in the past and can still use perfectly fine in every other scenario besides if PFSense 2.4.4 is used. This make me believe that the common fault is PFSense regardless of the sites motives and trustfulness. The only thing i can think of where it's not PFSense that's the problem is that in the update to the dns resolver feature its 'improved' things to the point its now incompatible with an old way of doing the dns checking or something that IPLeak uses. If this is the cases then that's great. I can accept that. My only issue with this being the case then stems from the question: How do i know for sure and how do i figure out where the fault actually lies?

Restart the dhcpd

I had similar/identical traceroute from a Mac OS X client and on the pfSense box itself using 127.0.0.1(unbound). Seems like it would be interesting to have unbound log when DNSSEC could not be used becuase the root keys are invalid, either the time on pfSense is wrong or the ISP is doing layer 7 manipulation. i.e. like what happens when you live in China, Russia or the USA...

Not yet possible in Unbound. There is an open feature request for that in Unbound itself. https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4089 See also: https://nlnetlabs.nl/pipermail/unbound-users/2018-July/010743.html

Thanks for the update. Good to see the Universal Windows Fix also applies to other stuff, too

You think connecting interface 1 to interface 2 on the same em host is a valid config? It is FUBAR and Borked plain and simple.. but overall I'd say that 70% of post I read on this forum are techs insulting the crap out of people asking for help.. Utter Nonsense... You joined 26 days ago.. If you find posts offensive Report them!!! I have been here 10+ years.. What you find is the same question over and over and over again from people to lazy to do any research on their own. Getting fed the info on silver spoons. What you READ into something is not my problem - if you take offense to stating something is F'd UP when it it... That is not someone offending you that is someone stating their freaking opinion on a public forum just like you have the right to do... I take offense at your post to be honest ;) Here you go complaining about someone saying what you did was BORKED... Vs providing some info to work with.. While I am not a hyper-v guru... I am sure there are others here.. I don't need to be a guru to understand you don't interconnect interfaces on the same vm host together.. Then we have one nic port bridged with the lan that goes to out printer and smart tv. Your nic is bridged where in hyper-v or pfsense? Why are you bridging interfaces in pfsense? If that is the case.. Do not use your host interfaces as switch ports... If you need switch ports - get a switch.. Is that what your doing? A network drawing would be very helpful.. Some logs? Changing your wan from dhcp to static would have zero to do with your other config.. So clearly something else going on that has nothing to do with that.. But without actual info of what you did impossible to guess - to start with what 2 networks did you connect together with your nics? Remove that - what doesn't work?