Did you try putting the toggle script in pfsense. I had a similar problem and saw this trick online which worked for me.
Login to you pfsense command line,
Create a new file using vi with the command -> vi /etc/rc.local
Add the lines below -

ifconfig de0 down (use the right name for your WAN port, mine was de0)
ifconfig de0 up
dhclient de0

save and exit
Then give the file root access by executing command "chmod 755 /etc/rc.local"
reboot

Hopefully this should work for you too.

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.

0_1540328105218_DNS Resolver Advanced Settings.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 😁