You can edit /etc/inc/services.inc, it is a PHP file related to the dhcpdv6.conf and dhcpd.conf
Source file in github: https://github.com/pfsense/pfsense/blob/fc79c7d3b9679c1246541aa7bf408d3f8299bfdb/src/etc/inc/services.inc#L1351

@choin, I concur with Derelict. I gave up using wireless bridges years ago for exactly the reasons you describe. In a word, they suck.
They also generally have very tiny MAC address learning capability, so if you have more than a few distinct MAC addresses on either side of the bridge it craps out.
Maybe there exists some unaffordable industrial equipment that works, but all the familiar names don't seem to have anything that works.
My 2¢.

I think it is fixed. Thank you @KOM and @Gertjan!

You don't want your AP acting like its own DHCP server. You just want it acting as a bridge from wifi to LAN or VLAN. Glad to hear your DHCP clients are now showing up. I'll have to remember that setting.

Your VPN issue should be a new thread in the proper forum, perhaps the OpenVPN forum.

Wow that was back from 2016 ;) nice that still came in useful.. And now we have the new info with the round robin.. Glad it worked out for you and I could be of help..

Yup thats us old guys bitchin at the users from the balcony - heheeh ;)

yes but pfsense use /usr/local/sbin/dhcpd

anyway if it's dhcp6c -> dhcp6-20080615.2_2

@sonic369 said in How to setup DNS Server:

Do we have any resolve ?

Why asking here ?

You instructed your pfSense it should hand out 8.8.8.8 as a DNS for your LAN clients.
Then you shut down the DNS Forwarder/Resolver, even for pfSense itself.
Now, if the communication to "8.8.8.8" and "8.8.4.4" goes bad, you'll be having a bad "Internet" experience.

@sonic369 said in How to setup DNS Server:

Today i have problem and i don't understand this DNS for PfSense.

Well .. what about not giving any private stuff like DNS request to Google and friends ?
(or did you sign some contract with them ?)
Go back to the defaults settings and you will meet the DNS experience of pfSense.
=> It plain works out of the box.

edit : @sonic369 : I've read you other 4 posts. Is that "issue" solved (you breaking the entire access to the Internet, and thus among that : DNS ...) ?
Really, use the default values, you'll be fine.

I want to keep my server in the same network range as the rest of my network that is off the 1st port from that card.

So you want to bridge your sfp ports?

So do that..
https://docs.netgate.com/pfsense/en/latest/interfaces/interface-bridges.html

@kiokoman You got it! I'm not sure what I was thinking by setting it to /32. Thanks!

Options 242 are common to all Avaya IP telephones
idk what option 243 is for
i don't think this dhcp options have anything to do with your problem but the only way to know for sure is to use wireshark and see what happen if you don't have anything else in the log

Weee. I have solved my issue. It's a kernel tune that needs to be done. I found out this on hardware forum that make this nice bords.

https://r.tapatalk.com/shareLink?url=https%3A%2F%2Fforum%2Eodroid%2Ecom%2Fviewtopic%2Ephp%3Ft%3D33911&share_tid=33911&share_fid=63351&share_type=t

Anyway I want to thx for all your help. It is very grateful.

@ttmcmurry said in Is it possible to view entries in the DNS cache?:

The log entry with the deny was from 10.10.50.50:<random> to 52.38.239.161:443, Flag TCP:A.

Well that is out of state, that is not a syn.. These are normal for sessions that have expired, or if the states on the firewall have been reset.

Say for example if you wan went down for a say even a minute, and you have it set to reset all states on a loss of wan (which I think is default?).. Now your client doesn't know this - so he thinks hey I was talking to 52.x.x.x just a few minutes ago - and now I want to continue the connection, so send just Ack..

Pfsense says hey wait just a sec there guy - there is no state for that = BLOCK..

You clearly got something odd going on there with all of those easy rules.. Why are you setting those.. Most of that is just noise that should be dropped, not going to go anywhere anyway. LLMNR is name resolution noise for L2 only..

Same shit goes for the WS discovery and mdns - these are all L2 protocols that pfsense can not do anything with anyway.

None of those rules should come into play at all anyway since your bottom any any rule would allow that traffic to not be logged anyway.

Just delete the thread.

I don't have neither time nor taste to explain this topic into more details.

Blame the developers of the XML standard which disallows such characters without special encoding. :-)

After running for the last week I haven't had any issues with not having a failover DHCP server defined.

Each firewall takes over their duties as expected when their partner isn't available.

I would like to get some final confirmation though; if anyone has been through this (CARP + DHCP server failover) please tell me if my setup seems strange.

That FQDN resolves just fine.

dig hwid7.vmall.com <<>> DiG 9.14.4 <<>> hwid7.vmall.com ; global options: +cmd ; Got answer: ; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18300 ; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ; OPT PSEUDOSECTION: EDNS: version: 0, flags:; udp: 4096 ; QUESTION SECTION: hwid7.vmall.com. IN A ; ANSWER SECTION: wid7.vmall.com. 3600 IN A 160.44.192.109 ; Query time: 303 msec ; SERVER: 192.168.3.10#53(192.168.3.10) ; WHEN: Sun Aug 11 11:38:08 Central Daylight Time 2019 ; MSG SIZE rcvd: 60

Do a dig + trace to help you figure out where the resolve process is failing.

Since it will walk down from roots resolving

$ dig hwid7.vmall.com +trace ; <<>> DiG 9.14.4 <<>> hwid7.vmall.com +trace ;; global options: +cmd . 81603 IN NS a.root-servers.net. . 81603 IN NS b.root-servers.net. . 81603 IN NS c.root-servers.net. . 81603 IN NS d.root-servers.net. . 81603 IN NS e.root-servers.net. . 81603 IN NS f.root-servers.net. . 81603 IN NS g.root-servers.net. . 81603 IN NS h.root-servers.net. . 81603 IN NS i.root-servers.net. . 81603 IN NS j.root-servers.net. . 81603 IN NS k.root-servers.net. . 81603 IN NS l.root-servers.net. . 81603 IN NS m.root-servers.net. . 81603 IN RRSIG NS 8 0 518400 20190824050000 20190811040000 59944 . U5tZLW1LD49PZHD6FtQTaEJuuIg1G1xtUb3wymW84x5MyFmrSkzud6zh HzuWWMOVTrBMQCcxa8Q0P1enkXk3s33RpF7dED4LynlrZij76tdI18rD LZ7LocZAih1P2Fpdtpnawa1BH2OJ2wScytFyXtp7og3ntcqe0L83petJ cQUG3D4JdkyHQV3/LjWTOTp+73hz8LZEXeSlFX7PLPTPsuAdVwib4+cp tRa3n3MI8Esu7OzjkHprk5SjWVLfCmK60JAQzWYeCEkPeew0q6tbJmSp PmCbjq34U0L4oM9v5gnonyLYmpSUZSjhVwbBww+I6i/xk/YSrTWycz9r ATq7Kw== ;; Received 525 bytes from 192.168.3.10#53(192.168.3.10) in 2 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com. 86400 IN RRSIG DS 8 1 86400 20190824050000 20190811040000 59944 . Au9ez+iicXM9ZCVNeBttnieOlMjtSLnFWS3fblB6yuJOPqAJDKlzGzH5 bo5A9agi+6ouB3di2J96Kdn2SE9Uq4mMaye4kQv7z7wUlthjwXadPAGq +nT4osIcOLxlWOCTLDBJnrCg6BnK7LoKMoleZjtQOr4ASNsW3CX3MEat SU/M+S9+Bg2NQeb+Z1rEieXIyG0zvlE+qzEg41rbuqFY3fk9kBMyB/sV 5lUeAZfAhlzH/jjKby+wJsaL+SRCPnstWgokekeZCHwXwJ4iHc2zRyCd 0e+FDT0z/7xouIYQVgt7GVQN0vQ/eUJBd9zhmCUbIfDi7w4AK9ykEJDU jVsVIg== ;; Received 1175 bytes from 192.203.230.10#53(e.root-servers.net) in 12 ms vmall.com. 172800 IN NS ns3.dnsv5.com. vmall.com. 172800 IN NS ns4.dnsv5.com. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20190815044522 20190808033522 17708 com. mZXFevDe/GAzLCPnKm123kkBDgeuHRJXSkMgsHkACMZmMmA5uCrvxXN8 7fTMTFFESSjd14PwgTavf5fJ4J4COTvIVHg7vrnztrt1JadLK3jXNPJ3 3Z8Cv5VINQMEPSAydR7XeZ8AMCvdkyEKB0jzpen719qTk4WWWAw33Jtw 9a8= BBB1CVUR8E83SHB84ISBAL4AU3ETEIFI.com. 86400 IN NSEC3 1 1 0 - BBB2HSGE6I0FF44AAKGTSAOUSUFOV8CM NS DS RRSIG BBB1CVUR8E83SHB84ISBAL4AU3ETEIFI.com. 86400 IN RRSIG NSEC3 8 2 86400 20190818042617 20190811031617 17708 com. B1lhNDgU3/6VBZl6Pup6vq5R0D+FFYv4WeLJMQXRpKt2WQLNdQUC5W1t 16PRQgRaWMLgEkhtz32glBlS7NTRxmJlWjvjR9oQG6je8l/YNYRnZJaw qebpAruEltXOxJWlxC7cr0lxiI/y6FYyzDMp/JCMVMT61u7k2RMYykwE WMo= ;; Received 907 bytes from 192.12.94.30#53(e.gtld-servers.net) in 32 ms hwid7.vmall.com. 10 IN A 160.44.192.109 vmall.com. 86400 IN NS ns3.dnsv5.com. vmall.com. 86400 IN NS ns4.dnsv5.com. ;; Received 126 bytes from 182.140.167.191#53(ns3.dnsv5.com) in 287 ms

I reinstalled 2.4.4_3 today. It starts correctly now. Fingers crossed that it stays like this.
Thanks for your guidance in this thread.
/T

You could have a /32 from your ISP, has zero to do with any of this..

Yeah I wouldn't see as an issue if you had actual connection with them... They prob not going to do it if you have the 200 a month "business" connection ;)

You should also be able to leverage that a colo somewhere, etc.

While yes selling bigger chunks is easier we just sold off some space - and pretty sure they were would go as low as /24s - how many /24s do you have total? And are you looking to sell all of them off.. I could send you contact I have... We did 3 different deals with them for 3 different chunks of space over the last year.. Went real smooth. Our smallest block was a /19