• DHCP is flipping, log full with ipv6 addressing

    4
    0 Votes
    4 Posts
    214 Views
    johnpozJ

    if you disable ipv6 on it - you would think it shouoldn't be asking for dhcpv6.. I would get with their support - maybe there is fixed firmware so it doesn't do that.

  • dhcp on serveral if's not handing out correct subnet/gateway on 1 if...

    2
    0 Votes
    2 Posts
    128 Views
    jimpJ

    Sounds like you have another DHCP server active on that segment handing out the unexpected information. Check on the clients, it should show more information about where they obtained their lease. Run a packet capture on the segment, see what traffic shows up.

  • DNS Query Refused over IpSec

    3
    0 Votes
    3 Posts
    638 Views
    L

    Ah, that fixed it! Thanks for the quick response!

  • 0 Votes
    12 Posts
    1k Views
    occamsrazorO

    @johnpoz said in Understanding DNS validating resolver w/ DNSSEC vs DNS-over-TLS and interception:

    And who says the info was not manipulated before cloudflare or google or whoever you forward to? They are just serving up what is in their cache - if has not been validated via dnssec, then it could be junk just as well.

    That is possible, I am aware. And I know you feel strongly from previous discussions that resolver is a better option, and I respect your experience and opinion. But let's look at the pros and cons...

    Resolver via ISP:

    Pros: Does not go through middle man, can use DNSSEC, DNSSEC-enabled domains can be trusted and if interfered with results would be rejected.
    Cons: Non-DNSSEC-enabled domains (of which it seems there are many) can be interfered with at the ISP level or anywhere inbetween. No DNS requests are encrypted so can be seen and monitored by ISP.

    DNS-over TLS with Quad9:

    Pros: Requests to forwarder are encrypted and can't be interfered with. ISP can not monitor the DNS requests (although obviously can do to resulting connections to the IP addresses). Forwarder implements DNSSEC themselves so results they give for DNSSEC-enabled domains should be accurate unless they are messing with it themselves. Optional blocking of malicious domains at the DNS level.
    Cons: Do you trust the forwarder?

    So yes, it really comes down to do you trust more the forwarder, or the ISP?

    @johnpoz said in Understanding DNS validating resolver w/ DNSSEC vs DNS-over-TLS and interception:

    Your just trusting them to not manipulate it more you trust your isp... Which to be honest doesn't make a lot of sense.. Who has more to gain from dns shenanigans some isp with x number of customers.. Or some site serving up dns to the globe? ;)

    Well I am talking about ISPs in developing countries where:

    There is no legal framework governing what they do. Security services get anything they want from them with no rules or legal basis. If they walk in and tell the ISP to redirect some sites DNS they'll get it instantly. There is little to stop some malicious ISP employee from doing same. ISP Employees have previously leaked large amounts of personal subscriber information including passport and ID card information. Their own security and technical expertise is poorer, and so chance of them being hacked by third-parties. An example - one ISP (not mine) previously ran entire neighborhoods of customers in the same subnet with no vlans or firewalls between them. There is no technically-minded local userbase to monitor, determine or complain if the ISP is doing bad things. No-one globally is looking at what they do.

    Versus.... Using Quad9 just as an example...

    A global DNS provider regulated as 501(c)(3) nonprofit organization (Charitable Organization, Educational Organization) founded by IBM, Packet Clearing House, & Global Cyber Alliance and based in California. A large global userbase capable of monitoring results, with frequent comparisons and tests made between it and other global DNS providers. As a result I would hope that if they were really messing with results, it would be found out by someone somewhere... and I don't see the incentive for them to do it given their nonprofit status.

    So yes... for me I do trust such providers more than my ISP.

    All of that said... I haven't been able to work out the issues I suddenly started having with DNS-over-TLS after it working seamlessly for a long time. I feel now the issue is something in pfSense not the ISP. But I don't currently have the time to spend on troubleshooting it so I'm sticking with straight resolver for now. While I still have less trust in its theoretical overrall privacy/authenticity in my particular situation.... I have to say it is performing very well indeed, is fast, and has had no issues.... so I may stick with it.

    PS - I'm aware for optimal security from local/country issues it's better to just use a VPN, and I do use that selectively. And have the capability to apply it to my whole LAN. But I don't find it suitable for use on all my LAN and general use.

  • LAN DHCP + VPN=OK + MGM static cant route?

    2
    0 Votes
    2 Posts
    161 Views
    H

    Hello,

    Actually this post helped me
    And this one with check if the outbound NAT rule is set on Automatic.

  • error: bind: address already in use

    3
    0 Votes
    3 Posts
    1k Views
    QinnQ

    I appreciate the suggestion, but that one is not enabled in the resolver.

  • dhcp dyndns intergration with samba dns

    3
    0 Votes
    3 Posts
    615 Views
    adamwA

    It looks like there is no way to integrate without Kerberos authentication:

    https://wiki.samba.org/index.php/Configure_DHCP_to_update_DNS_records_with_BIND9

    Unless somebody can share a successful story.

    Are there any plans to expand Dynamic DNS section in pfSense DHCP settings to support it?

  • Cloudflare DNS IPv4 and IPv6

    5
    0 Votes
    5 Posts
    1k Views
    P

    You shouldn't need to enable dnssec if you're using forwarding mode with cloudflare. Also add the cloudflare hostname to enable hostname verification for the DNS servers. You can paste this in the hostname value for all 4 cloudflare DNS servers that are listed: 1dot1dot1dot1.cloudflare-dns.com

    Also for what it's worth the ip4 DNS servers still return ip6 results. So even if you only have the ip4 servers configured you'll still get ip6 results. Also try https://1.1.1.1/help for cloudflare diags.

  • DHCP and VPN Layer 2 help

    1
    0 Votes
    1 Posts
    267 Views
    No one has replied
  • BUG? - DNS Resolver Access List /31 UI Issue

    3
    0 Votes
    3 Posts
    309 Views
    M

    https://redmine.pfsense.org/issues/9586

    Lodged a redmine ticket here.

    Thanks

  • DHCP in multiple PFSENSE BOX with same IP Pool

    8
    0 Votes
    8 Posts
    828 Views
    slkamathS

    Ok. Thank you very much.

  • AD domain controller as local DNS, forwarding to PfSense

    10
    0 Votes
    10 Posts
    2k Views
    KOMK

    I don't see anything out of the ordinary. Are you using SSL/TLS with Resolver? Perhaps disable that if enabled, and try different DNS servers to see if the problem persists.

  • DHCPv6 Static Leases - How to set uniquely per interface (DUID + IAID)?

    1
    3 Votes
    1 Posts
    557 Views
    No one has replied
  • 0 Votes
    3 Posts
    192 Views
    L

    Yes dhcp is configured on each vlan since we want to be under 250 ip's.

    The only relevant msg is :
    which I believe is related to me stopping and starting the service .

    /status_dhcp_leases.php: The command '/usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid re0 re0.12' returned exit code '15', the output was 'Internet Systems Consortium DHCP Server 4.3.6-P1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Config file: /etc/dhcpd.conf Database file: /var/db/dhcpd.leases PID file: /var/run/dhcpd.pid Wrote 383 leases to leases file.'

    I'm forced to setup a backup windows dhcp server and disable the dhcp on pfsense...

    Troubleshooting on client, it keeps saying that it cannot get ip address ,and will use local 169.254 until it gets an address...

    There is a bunch of dhcp leases that are "offline"
    At one point we only had 8 dhcp leases online,

  • No internet or admin interface after enable DHCP on lan

    5
    0 Votes
    5 Posts
    192 Views
    O

    After resetting all is working fine.
    Thanks for reply /help

  • Windows dns and pfsense vlan

    1
    0 Votes
    1 Posts
    139 Views
    No one has replied
  • PFSense not playing nicely with Android TV

    21
    0 Votes
    21 Posts
    6k Views
    M

    I was having a myriad of issues with an Android P device after upgrading to 2.4.4_3 and also having SSL/TLS DNS turned on; this would cause intermittent DNS lookups to take an excessively long time (2-3 minutes). I don't use forwarding. I captured packets and there was a ton of TLS spam between pfSense and said device, all for DNS, with intermittent communication breakdowns and retries.

    Being that I probably gave the settings a once-over when doing the upgrade to 2.4.4_3, I am unsure whether it is something specifically in that version or if it's a coincidence. Regardless, turning off is a workaround for now. I'm not sure if a proper certificate is needed for this to work properly or if it's just a bug.

  • Authoritative DNS server behind resolver (unbound)

    18
    0 Votes
    18 Posts
    6k Views
    S

    After updating from pfSense 2.4.3 to 2.4.4p3 my LAN clients received SERVFAIL for domains I control. According to unbound logging I was still getting a response from Dnsmasq forwarder, and dig/nslookup against forwarder worked fine, so I assume Unbound was upset about the ra flag in the response. (Dnsmasq really isn't supposed to be used this way.) Rather than hacking Dnsmasq code I have replaced dnsmasq with this script to forward Unbound's query packets right to my authoritative server. Python is available in the package manager.

    https://github.com/kongluoxing/py-simple-udp-proxy

  • dns resolver - unbound

    7
    0 Votes
    7 Posts
    763 Views
    D

    My apologies. The image reinstall did resolve the issue. I forgot that as a work around for unbound not working, I installed dnsmasq. I forgot to turn off dnsmasq before starting unbound. Thanks for listening.

  • DHCP on LAN out packets lost when LAN bridged to another interface

    10
    0 Votes
    10 Posts
    736 Views
    johnpozJ

    Dude you created a LOOP.. .that is going to cause all kinds of ODD Shit!!

    You you can not run it this way be it home, or a lab or an enterprise. It will not work!!

    I already suggest you could try using the igmp proxy.. But if all you need is mdns discovery, then yeah avahi might work.. Can tell you that getting chrome to work across different L2 is going to be a PITA..

    Use something else would be my suggestion. Not sure exactly in what context your using it in..

    If you want pfsense to filter between the bridge.. Then your going to need another physical interface on your vm host, so you physically separate the L2 you want to filter/bridge between 2 physical networks via different switches. Or a smart switch that you could isolate the L2 via different vlan tags.. You could then bridge across these 2 tags vlans and make them the same on pfsense doesn't have to know about the tags, etc.

    So with a smart switch you could do something like this..
    bridgewithsmart.png

    You create 2 different vlans on your switch.. You then isolate these different vlans on your esxi into port group for each vlan.. Then you connect these port groups to 2 different vnics on pfsense that not using tags.. esxi will strip the tags let the port groups handle the tags..

    You bridge these interfaces on pfsense.. So you have 2 isolated L2, that you have bridged into a single L2 via pfsense.. So computer on Y not talk to X unless it goes through the pfsense bridge.. Now you can filter and say no Y can not talk nas on vlan X via L3 filtering..

    But if your switch is not smart and can not isolate the vlans.. Then this can not work!!!

Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.