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.

Afraid I don't get the issue at all. Try on some of other language boards under International Support.

@rovshango:

Well I think my answer to this question will help "me" :)

I want user to login CP (with provided user/password), after 59 min user should disconnected.

The hard timeout will do that.

Also to release/free IP address which he took.

Captive portal happens after a DHCP lease has happened.  Every device can get and keep a DHCP lease whether or not they even try to get on the internet or even look at the captive portal.

So maybe he will not re login after disconnect (59).

That is a function of whatever authentication backend you're using for captive portal.  Not DHCP.

This is all assuming open, not WPA, Wi-Fi.

Yes, and the good part of the extra field option is, as I've seen javascript used to change the visible fields for example when you choose custom from the list, the extra field could be made to only show when using dynamic DNS providers where this could be an issue.

The back-end code is in /etc/in/unbound.inc
I added a comment to https://redmine.pfsense.org/issues/4367

Looks better now…

I differ. It is actually a good thing you offload pfsense for regular intervlan routing, and maybe the most important reason being that your L3 switch does that routing way more efficiently, no need to change that. (it's another story if you need/want security between those vlans but that was not your question)

There's a "but" though here. Currently it is only possible to configure dhcp scopes for "own" subnets. Meaning, if the subnet is not assigned to any physical or vlan interface, you won't be able to have it hand out dhcp offers to anything (scopes) it does not know.

It is (or better technically it can be) possible to have all dhcp to be handled by pfSense, possible but not standard yet. (see https://forum.pfsense.org/index.php?topic=65736.0)
You will also need ip-helper on each SVI on the L3. (easy part)
I have it running with good results…

If you don't go with the mod by Marcello, the only way to accomplish that dhcp story is by presenting each vlan to pfSense, either physical, either by dot1q.

If the local-zone configuration option works the way it sounds like it should, then this should be a more direct approach by using the unbound configuration options.

https://unbound.net/documentation/index.html
https://unbound.net/documentation/unbound.conf.html

local-zone: static