@johnpoz said in Setting MTU via DHCP:

Dude so your running jumbo on your home network??? Come on - let me know how you set your printer to use jumbo.

I have experimented with jumbo frames and they do work. However, since WiFi doesn't support them and my AP is connected directly to the LAN, I can't run jumbo frames on a regular basis.

It's kind of like your attitude towards ipv6.. You have it in your head that its the STANDARD, and required.. No matter how much you want it to be.. It just not here yet.. How many iot devices support it... how many actual isp support it? etc etc. Name 1 major internet resource that I can only get to on ipv6.. You can not..

IPv4 has not been adequate for years, as there are not enough addresses to go around. As a result, we have hacks like NAT and STUN to get around that. Yes, we should all move to IPv6 because IPv4 is not adequate. While I am not personally aware of servers that I cannot reach, there are large parts of the world where IPv6 is widely used, as IPv4 addresses are not available. There are also many who can only get NAT/RFC1918 addresses, which means they have no way to reach their own network from elsewhere. That alone proves IPv4 is not adequate.

Its just like this jumbo nonsense... Sorry but it has no use... Maybe when we are all running 40gig on local networks it will be, but currently sorry its just not the case.. How about you get with all the iot makers to get their shit to do jumbos and then maybe we can have a discussion on why not running it ;)

As I mentioned, some carriers and ISPs are already moving to 100 Gb. One that I have experience with, though not at 100 G is Cogeco Peer 1 (Peer 1 has recently split from Cogeco). So 100 Gb is on the way, though not at the consumer level.

Funny you should mention that. I bought a new TV a couple of months ago. It connects at 1 Gb. In fact the only thing on my network that doesn't, is my AP. However, that TV did mess up the WPA2 password, in that it won't accept the full 63 characters.

The OP can do what ever he wants... His original question about mtu and dhcp has nothing to do with pfsense at all.. It's a windows issue.

Yes it is a Windows issue as the DHCP client should work with any MTU. There's a long list of things Microsoft broke over the years. However, as it provides the DHCP server, pfSense should support any MTU and it does.

@Peek said in DNSSEC Lookaside Validation:

Is there thus another workaround ?

Move your domain to a different registrar..

Your problem is some tld do not support it, so no registrar can support it either.. So use a different tld for your domain if you want dnssec

http://stats.research.icann.org/dns/tld_report/

If the tld does not support it, you would have to complain to the owner of the tld.. But those are not actually tlds, those are subs off the tld.. You would have to get with the owners of those to get them to support dnssec, before you could ever get yourdomain.com.au or yourdomain.co.za

I just checked and both com.au and co.za are delegated with dnssec from their parents... So you should be able to find a registrar that supports it.

The easier option would be to just use different domain that is supported at the registrar you like ;)

edit: So I looked in to co.za a bit, and they for sure support dnssec.. If your looking for actual registar you can use that supports it for that domain you might want to contact
https://registry.net.za/contact.php

Ok sure looks like they support it
https://vweb.co.za/

dnssecregistar.png

The site does look a bit lame ;) But pretty sure they support it, so you could contact them - and if they do.. You can just transfer your co.za domain to them as registrar.

That sad part in the whole thing - is pretty sure if the registrar is accredit pretty sure there is a rule that says they need to support dnssec for any domains they accept.
https://www.internetsociety.org/blog/2013/09/icanns-2013-raa-requires-domain-name-registrars-to-support-dnssec-ipv6/

That went into effect back in 2014..

Here is the RAA
https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en
Here is direct link to the dnssec section
https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#operation

DNSSEC

Registrar must allow its customers to use DNSSEC upon request by relaying orders to add, remove or change public key material (e.g., DNSKEY or DS resource records) on behalf of customers to the Registries that support DNSSEC. Such requests shall be accepted and processed in a secure manner and according to industry best practices. Registrars shall accept any public key algorithm and digest type that is supported by the TLD of interest and appears in the registries posted at: http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml and http://www.iana.org/assignments/ds-rr-types/ds-rr-types.xml. All such requests shall be transmitted to registries using the EPP extensions specified in RFC 5910 or its successors.

And here is the list of accredited registrars - per that doc, they are really required to support dnssec..
https://www.icann.org/registrar-reports/accredited-list.html

Since they all signed the RAA.

So guess you could BITCH to your current registrar, or complain to icann about them not actually supporting it.

If you ask me its the registrars that are holding it back from how it should be.. They don't make it simple enough to do, some do namecheap for the domains they do it for is easy, dynadot is pretty easy to use... I have domains with both that are dnssec enabled. I know for fact cloudflare supports it, but don't have any domains with them. Might move at some point?

But many don't have any interface for any of their domains they support.. Which per the RAA they signed puts them in violation.. And they could loose their accreditation.

I was just following there tutorial. I diddnt know if i had to use there DNS.
Furthermore they never updated there tutorial to the new version.

If you want

hostA.domain.tld to return local
hostB.domain.tld to return public
hostC.domain.tld to return local

Then you would have to create host overrides for each specific fqdn that you want to return local.

Or you can go the other way and do a redirect, and then just create records that point to your public IP for those fqdn.. Depends on how many you have on what side, etc.

Yeah, that's what I ended up doing, pointing all clients to my bind servers, then having the bind forward to pfSense, then pfSense forward to Google and Cloudflare. I put in domain overrides for local domains and reverse domains for my LAN, and that seems to be working and for the most part it seems pfBlocker is now working as expected.
A little more convoluted than I originally imagined but actually makes sense since pfBlocker is acting as a DNS Rewrite engine it would have to be the "final say" for clients on the LAN.

Damn. Sometimes....

A "ipconfig /flushdns" did it.

@costanzo said in DNS over TLS with pfSense:

I was wanting to use DNS over TLS to make it harder for Comcast to capitalize off of the DNS data.

So you your just letting xyz that you forward capitalize on it ;)

But when you resolve - you are sending queries to the authoritative NS directly - your not handing anything to comcast - they would have to sniff all dns traffic and record it, etc. not just parse the logs of their dns server(s).

Keep in mind - they can still tell where your going even when https via the SNI that is in the clear.. Be it they have your dns traffic or not, etc. etc.

What you do for sure when you have your dns go over tls - is take a huge freaking hammer to the overall performance if you ask me ;)

@JKnott Not yet, but I'm traveling and won't be able to test until early next week. I will do so and respond upon my return.

Well, those are two common ways of redirecting web traffic. It's not as easy as just checking a box or something. Also, you can end up breaking https if you do that, and you may get certificate errors in your browser.

register the devices under static mappings.

then under services > dhcp server > static mappings > edit the device and under DNS servers put in the DNS server of your choosing

If your having issues with unbound - bind can resolve and do dnssec as well.. Bind is the dns of the internet for a reason.. But would be curious to find out what is causing your issues with unbound.

I have been using unbound on pfsense since before it was built in, and just a package.. And other than the restarts on dhcp registration restart issues have never hand any issues..

I personally see no reason for dhcp reservations of dynamic clients - clients I need to resolve I always setup a reservation for. So my setup is just register those.

@sdouc said in DNS Resolver with forwarding mode:

How is this different from enabling the Forwarder with the Resolver disabled?

Two different programs. Click for all the details.

Hi Gertjan,
We forward the logs in a syslog server, and then the relevant ones in a Security Information and Event Management system (SIEM), splunk based. So we can always investigate in the syslog server (no log dropped at all), but for our security needs, internal DNS requests are irrelevant and I don't want to pay to index them in splunk.

Hi @rajat - In general, the way I would recommend to set this up is:

Clients on LAN Subnets send DNS Request to Pi-Hole --> Pi-Hole checks its DNS cache, and if needed forwards the DNS request to pfFsense --> pfSense checks its DNS cache and if needed either resolves or forwards the DNS request (depending on if you have Unbound setup to run in resolver and forwarder mode).

In your case I see that you have Pi-Hole setup on your 192.168.100.x LAN subnet. Make sure you have added the necessary firewall rules to your other VLAN subnets to allow clients on those to send DNS requests to Pi-Hole, and then change the DHCP information on the VLAN subnets to make sure that Pi-Hole is assigned as the DNS server to clients. In Pi-Hole itself use the pfSense LAN IP as the upstream DNS server for Pi-Hole to talk to. Inside pfSense, decide if you want to run Unbound as a DNS Resolver or DNS Forwarder. If Resolver, there is no need to enter any additional DNS servers under General --> DNS Settings because pfSense will always resolve (i.e. talk to the DNS root servers first) if the DNS information is not available in the cache. If you are running Unbound in forwarding mode, you can enter your forwarding DNS servers in General --> DNS Settings.

Also, regarding NAT redirects: Right now I see that you have only have one NAT redirect rule on your LAN subnet. I don't think this will rule will do anything since any traffic originating on the LAN subnet 192.168.1.x bound for 192.168.1.100 (also LAN subnet) will not need to cross (i.e. talk to) the firewall. I think what you actually want is NAT redirect rules for each of your other VLAN subnets to ensure that if DNS traffic (originating from them) is not bound to Pi-Hole it gets automatically redirected to Pi-Hole.

Hope this helps.

Disabling IPv6 did work in my case, although you don't need to disable it on the PC's if you do it directly in pfSense.

Braindead morning post - should have said UNBOUND. Reposting.

Just to add more details: "Enable bypass for LAN interface IP" would not work since, vlan110 was not the first interface i had created, and this other interface is the "Hardcoded" LAN now(first LAN was an administrative IP, just to deploy the VM).

Another issue here is that I have technically more than one LAN, and all of them will need to use dhcp-relay(desktops vlan, voip vlan, guest vlan, wifi vlan, wifi-collectors vlan...)

If i could create a bypasslan rule inside ipsec.conf with 10.x.0.0/16(a broader scope) maybe this would do the trick, but i'm afraid ipsec.conf will be overwritten by config.xml, and that one uses the lan xml tag to define this behavior.

Any tips how can i achieve this here?

Here's what I see in the system logs when domain override is not working. I've obfuscated the actual host name by replacing it with host.domain.local in the log below.

Jun 26 11:51:02 unbound 39647:1 debug: cache memory msg=2104630 rrset=3021363 infra=2591404 val=313689 Jun 26 11:51:02 unbound 39647:1 info: validation success host.domain.local. AAAA IN Jun 26 11:51:02 unbound 39647:1 info: validate(nxdomain): sec_status_secure Jun 26 11:51:02 unbound 39647:1 info: validator operate: query host.domain.local. AAAA IN Jun 26 11:51:02 unbound 39647:1 debug: validator[module 0] operate: extstate:module_wait_module event:module_event_moddone Jun 26 11:51:02 unbound 39647:1 info: finishing processing for host.domain.local. AAAA IN Jun 26 11:51:02 unbound 39647:1 info: resolving host.domain.local. AAAA IN Jun 26 11:51:02 unbound 39647:1 debug: iterator[module 1] operate: extstate:module_state_initial event:module_event_pass Jun 26 11:51:02 unbound 39647:1 info: validator operate: query host.domain.local. AAAA IN Jun 26 11:51:02 unbound 39647:1 debug: validator[module 0] operate: extstate:module_state_initial event:module_event_new Jun 26 11:51:00 unbound 39647:0 debug: cache memory msg=2104630 rrset=3021363 infra=2591404 val=313689