So pfsense is your first solution that isn't broken ;)

You can not have reservations for 2 different macs for the same IP.  This could cause a duplicate IP issue..

This concept of putting same IP on either a wired or wireless is pointless..  Why would anyone want or need to do that??  For one - wireless should really be on its own segment in any real setup.  If you want to run with broke setup then change either your wired or wireless to have the same mac - there you go problem solved ;)

If on the same segment, then they should have or get different IPs because they have different macs what does it matter if when wired 192.168.1.100 and when wireless 192.168.1.200 ?  If you need firewall rules use both IPs and setup 2 different reservations.  If need be change your segment to /23 and wireless get 192.168.0.100 and wired get 192.168.1.100 makes it easy.

Why is it you think these 2 different interfaces need to have the same IP address?  Dynamic dns registration removes the issue of having 2 different names, etc.  If they are wired host.yourdomain.tld points to the wired IP, if wireless host.yourdomain.tld points to wireless IP.

@cmb:

Make sure you have "harden glue" enabled on the Advanced tab. If you don't, it might be possible for some malicious query reply to break a TLD.

I just activate "harden glue", and it works:-) Thanks!
But I do not understand what is this option. You can tell me more?

You are getting DHCP from somewhere else, not pfSense.  Make sure there are no other DHCP servers on your network.  The client might tell you what it thinks its DHCP server is (ipconfig /all in windows, for instance)

Unbound is simple - I'm sure you can handle it with ease.

Its easy to configure pfsense so that it "leaks" DNS.  Its also easy to configure it so that it doesn't.

IPV6 DNS is easy to forget about running in RADVD.  Also easy to forget DNS running in the basic config section of pfsense.

Then there is the vpn client its self.  How do you know its not a problem at the client end?

Let it run for a bit longer and noticed that the DHCP service crashed on the box. I guess this is a bug.

Update: I've created a bug report on redmine: https://redmine.pfsense.org/issues/4408

Update 2: Disabling DHCP failover solves everything. That's a workaround for now.

Leaving this topic for others with the same issues to find.

drop ip any any <> $HOME_NET any (msg:"OBFUSCATION A"; content:"a"; nocase; content:!"fuckin'": nocase; classtype:non-standard-protocol; sid:633321004; rev:1;)

Yes, I go through the entire thing right to the end until I get the standard NICs & Options screen.  One thing to add is that the LAN subnet already has a Windows AD DHCP server.  He dishes out in the 10.10.2.x range.  I don't believe he's part of the problem but I wanted to mention it.

I don't think the dns forwarder is going away any time soon.  The option is there to run both if you want.  But this new move to the resolver is confusing for many users, and having the over rides listed - its possible for example to do what you did put your over rides in the same section.

Its hard coding for layer 8 ;)

@Derelict:

Harden Glue appears to correct this, but that's pretty anecdotal.

Never could reproduce this lolcal issue… I have harden-glue: yes enabled everywhere. So, sounds like a pretty good guess I'd say.

@cmb: Can we get harden-referral-path exposed in the GUI as well? (Probably not default on, but visible.) Also, harden-below-nxdomain.

I'm just trying to implement this, Did you figure it out?

Ha! Sorry, my first time using github. Here's the link:

https://github.com/pfsense/pfsense/pull/1479

I have turned off IPv6 everywhere. A reboot of the client seems to have removed the ipv6 dns entry. I tried ipconfig /release and /renew before hand. But a reboot seems to have cleared it.

The answer to the CPU load problem was here https://forum.pfsense.org/index.php?topic=87513.0. I disabled layer 7 shaping and, after a reboot, the CPU is back to normal and there are no more "ipfw-classifyd: packet dropped: output queue full" messages in the log.

And after a few more tests with various other devices I can confirm that disabling Layer 7 traffic shaping also resolved the DHCP issue - all my wireless clients appear to work fine again.

it seems to work only if i use ram disk for /tmp and /var
it makes no sesnse to me…but...seems to work fine now.

@Trel:

I'm curious for people having this issue.

Can you make a Match+Log floating rule and see if any of these IP ranges are being contacted in the general timespan before this occurs?

212.6.128.0/17 195.22.0.0/19 54.72.8.183/32

I just did a packet capture and I found a DNS query for:```
api-nyc01.exip.org

Shortly after that, it happened again.  It seems to be connected in some way to querying for that name.

@phil.davis:

Forwarding mode should forward all requests to the designated upstream DNS server/s.
Thus there will be no reason for Unbound to ever consult the root servers, because it never does a recursive resolve when in forwarding mode.
That is the theory. Of course there might be "bugs/features" in the code that result in some talking to root servers even when forwarding mode is on - you would have to audit the code and test to really know that :)

Got it! I was just thinking that it's like the DNS server in Windows Server wherein there's a checkbox for "use root hints if no forwarders are available" under the forwarders tab.

And by the way, can you guys help me out in another thread? I decided to separate it here: https://forum.pfsense.org/index.php?topic=88164.msg486107#msg486107

Thanks.

Again, you are restricted only really by the limitations of the hardware you're using. A 2Gb network card should easily be able to manage 400mb bandwidth. It's a firewall so I should hope it can NAT traffic - it'd be pretty useless if it couldn't.