Thanks John. Your approach actually makes better sense. I'll stick with Unbound's default config. Thanks for the clarification.

OpenDNS has been anti-DNSSEC for ages and stuck with their own wheel re-invention (typical DJBware). So yeah, they are just unusable for DNSSEC.

Thank you :). Sometimes you sweeten what is nearby. I see the log to dnsmasq that they were recorded and through dig. ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1280 ;; QUESTION SECTION: ;example.com.                    IN      MX ;; ANSWER SECTION: example.com.            1      IN      MX      10 mail.example.com. ;; ADDITIONAL SECTION: mail.example.com.        1      IN      A      192.168.1.50 ;; Query time: 2 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sun Dec 06 19:29:18 CET 2015 ;; MSG SIZE  rcvd: 86

well this is not that its not returning an answer because it didn't know or couldn't find – that looks like you just got a timeout.. Because it sure looks like your unbound is starting and stopping all the time.. So either it was off you asked. Uncheck "Register DHCP leases in the DNS Resolver" in the resolver settings and see if that helps it from starting and stopping every few minutes.

Ha. by "lots of RST action" I meant that many of the calls to the MS servers were being responded to by RST packets by their systems. Because the range and quantity (sometimes just a few, about 10 in a row; sometimes a lot, upwards of fifty, followed by a pause of 5-10 seconds and then another round, etc…), and the fact that they were happening on IPv4 as well, I was tending to rule them out as a factor at all but included the mention for completeness... Since originally posting, I've had to travel a bit and some locations were offering IPv6. However, they all worked! It turns out that in every case, despite having a v6 address, DNS resolution always pointed to IPv4. So much for that! Because of that, I also agree that by resolving their servers in IPv4 will be the fix du jour - until they get their issues resolved. Having worked with MS in the past, the best way is to do as much research as you can prior to contacting them. Which I'll do again shortly (and report back if something useful comes of it). This discussion has been a great help for that.

It looks like it's a problem between the master-firewall (that was upgraded from version 2.1.5 to 2.2.5) and the new slave vm-firewall (that was build up from scatch with 2.2.5). The error with ipv6-adress conflict doesn't occure, if we disconnect the master-firewall. If only the new slave-firewall with the syncronized settings is running, it works. But it's not possible to isolate the cause the problem. Also one IPSec-tunnel doesn't work anymore at the upgraded machine, but the same tunnel is working at the new machine. It seems, that there are some issues by upgrading the machine.

Wow that's awesome- exactly what I was looking for. I agree, burying your head in the sand isn't usually best practice. But in this case it was the lesser of 2 evils so I won't miss other important messages. Thanks Chris

The underlying software doesn't support that. You'd have to use two NICs.

I can confirm that there are some serious issues with USB ethernet adapters. I also tested the above mentioned ASIX AX 88772 and had the same problems as the thread opener: pings to IPs do always work, DNS lookups do never work and standard TCP transfers do work sometimes. If, with the same config, I replace the USB by a PCI card, everything works fine. The reason why i did this: USB card is 9€, low profile PCI card + 90° riser card for this case is 55€, but the time I spent working on this problem is worth way more… If you want to see some serious shit, look at the attached Wireshark capture. This was captured on my home router (192.168.66.2), with 192.168.66.21 being a windows machine making a reference lookup and 192.168.66.199 being the USB-WAN interface of the pfSense machine in question. Don't ask me why I don't get any query responses (but two) to the pfSense machine's requests... [dns problem.pcap](/public/imported_attachments/1/dns problem.pcap)

Okay I will post the screenshot after disabling it. Once again thank you for your kind help.

Yes, doing a whitelist is PITA.  I had about 12 hours into configuring it, and 12 hours into testing it in a real environment.  The most apparent breakdown was with Exchange 365, because it is hosted on a massive data center like the Akamai network, and its IP addresses change all the time.  Exchange would go down for 15 minutes or so at a time, about once every 48 hours.

You dont see anything wrong?  As mentioned already u should really look to hiring some people that understand this stuff.  You seem way out of your league sad to say

Adding the alternate hostname to access the configurator pages does not help. One of my websites is working from the outside, and so is the configurator… root.ca works at rProxying to 10.0.0.1:443 pfsense.root.ca works at either my public IP, or it is going through the rProxy to 10.0.0.254:443...not sure. dsm.root.ca gives the rebind issue...If I disable rebind checks, it shows the configurator page. Though I want it to go to 10.0.0.1:5001 Any advice on this issue would be appreciated.

.fast and .ipmi would not be subdomains…  host1.fast.domain.tld would make fast a sub domain or host1.ipmi.domain.tld I have these sorts of names for pfsense different interfaces so when you do a PTR you get back the correct ip for that interface.. C:>dig pfsense.dmz.local.lan +short 192.168.3.253 C:>dig -x 192.168.3.253 +short pfsense.dmz.local.lan. Since your setting static, you can just do an override for whatever name you want for each of those IPs.

For those looking for this, I ran into the same situation recently. DNSexit's remote update service is kind of annoying, its algorithms are not so optimized apparently. It has some sort of cache and it will always tell you that your IP hasn't change if you have once before submitted that one IP. Even if the host has now a different IP in you account then the one you're passing for update. But we still can make that work with pfSense (I'm using 2.2.4-RELEASE (amd64)): Create or modify your Dynamic DNS client configuration and set the Service Type to "Custom". Choose the interface normally and then supply the "Update URL" using the following sintax: http://update.dnsexit.com/RemoteUpdate.sv?login=YourLogin&password=YouPassword&host=YourHost&myip=%IP%&force=Y The "force" switch is the most important here, it will bypass the "IP not changed" misunderstanding messages. And pfSense will repace %IP% with your public IP (for the interface you choose). As per DNSexit's own instructions (for the URL): "replace the values with your own account and domain data. myip is optional. If not set, the IP address of your network will be detected and used as the IP for the host(subdomain). host can have multiple hosts(subdomains) updated at the same time by seperating each host by ;. ie. host=host1.mydomain.com;host2.otherdomain.com. password is the password for your web login. However, it is recommended that you setup a dynamic IP update password that is different from your web login password. You can login to your account, then go to "Account Profile" -> "IP Update Password" to setup dynamic IP update password. " The IP Update Password is a good ideia, since this traffic is not encrypted and your password goes in plain text. So, your configuration will look like the one attached, where the full Update URL example is something like http://update.dnsexit.com/RemoteUpdate.sv?login=mydnsexitaccount&password=Samp1ePassw0rd&host=web1.mydomain.com&myip=%IP%&force=Y Then the Cached IP field will no longer show 0.0.0.0 (in red). Sometimes it will show a N/A, but eventually will show the current IP (in green). If not, edit the configuration and use the "Save & Force Update". Cheers, Victor. [image: pfSense_DynamicDNSclient.jpg] [image: pfSense_DynamicDNSclient.jpg_thumb]

If you want traffic from public to talk to devices inside your network, this is normally done with a port forward.  You would simply port forward 80 and 443 to the private IP address you want to send that traffic too.  If you need to do it based on fqdn or url then you would use a reverse proxy yes.