@daddygo said in PS4 ip problem with failover: Just to clarify, are we talking about pfS HA? Yes

@cnliberal Check the domain name with https://www.zonemaster.net/domain_check. The next time you 'rent' a domain name, check the quality of the registrar's services. Issues like "ns1.carle.com" and "ns2.carle.com" are using the same AS, and are even in the same network. That's not ok. You can correct this, by adding a third one (or remove the second and replace it for another, elsewhere). Slave DNS name services can be found for free on the Internet. Issues like : [image: 1632900433032-809b9573-0312-489f-839e-d28d568095ef-image.png] is also something that had to be dealt with, many years ago. Who is this registrar, the local hobby club ? ;) You're aware now that there are 13 'main root servers'. These know where to find all the top name severs, the ones know all about 'com', 'org', 'net', etc. These top level name servers have many 'clones'. The bottleneck are the (minimum) two domain name servers, your "ns1.carle.com" and "ns2.carle.com". These two have, of course, firewall rules that to filter out 'abuse'. And guess what, what is the third reason why people use VPN's ? Right : to abuse a max. ( the third reason : just to loose some money, and the second : hiding their public WAN IP ) Which means : when you connect to your VPN, and you get an IP that was 'used' for some abusive activity, the IP will get blacklisted for a while. At that moment, you, withthat VPN WAN IP, will have issues when resolving domain name that are registered (known to) "ns1.carle.com" and "ns2.carle.com".

@1ntr0v3rt3ch said in Add DNS in DHCP Server Settings: Required?: I am using unbound and it is running well. no issues in services. Just because the service is running - doesn't mean its working. It needs to be able to resolve. If it can not - then no it can not answer queries from clients. You need to validate that unbound can actually resolve what your wanting query for - say www.google.com example: [image: 1632826628338-dns.jpg] See where only loopback 127.0.0.1 was used (unbound) and it returned an answer. Do such a test.. And post the results. If no then no clients asking pfsense IP to look up something is not going to work.

@stewart it shouldn't - resolver would have nothing to do with those.

@jgauthier There are some DHCP-client settings that might be useful here : These : [image: 1632751693954-679bda3d-cc95-4d9e-956c-c4c8c55c2866-image.png] Check the 'Advanced Configuration' to see them. Click on the blue "here" link for guidance. Strange that, after a interface UP event on "09:35:34", more then 3 minutes later, on "09:38:52" there is still no answer. The DHCP client assigns a previous used IP 47.77.33.59. It would be better if it assigned itself a NaN IP like "0.0.0.0".

@1ntr0v3rt3ch said in Unable to resolve opensuse.org with pfSense DNS resolver: https://forum.netgate.com/topic/166780/add-dns-in-dhcp-server-settings-required/8 When you set up pfSense, there is no need to enter any where '8.8.8.8' or '8.8.4.4'. These two - or any others - are mentioned no where in the Pfsense manual. Again : the default Resolver doesn't need any setting to be altered : it works out of the box. But : if you have some sort of contract with Alphabet cooporation - (aka Google) that you have to hand over all your 'private' DNS request, then, ok, why not. I don't think an ISP exists that actually blocks you from accessing basic Internet servers like the 13 root servers. And even if they exist, because, after all, it's a free world, so why not. It will be the ISP without clients, that's for sure.

@mr_jinx The "value", according https://developer.apple.com/news/?id=q78sq5rv must be a JSON API file. This file shows an example how the connection phase works. As you can see, this file doesn't contain a static value. An non logged in device would retrieve : { "captive": true, "user-portal-url": "https://example.org/portal.html" } After login, the same JSON API file could show : { "captive": false, "user-portal-url": "https://example.org/portal.html", "venue-info-url": "https://flight.example.com/entertainment", "seconds-remaining": 326, "can-extend-session": true } The good new : IPv4 and IPv6 ready. This will simplify the "get the login page shown to the client" a lot. 'https' isn't an option here : your portal will need valid certificates. From what I understood, IPv6 is still optional. I played with this 'DHCP 14' option, and it worked well. Dono / didn't test any Android devices .... edit : this is still 'draft' .....

@viragomann Thank you it works, actually remote site DNS server was on another VLAN, when i give static route of the dns server, it resolve.

@cubeyglyph no problem.. Its not that I hate the idea of doh or dot.. What I don't like is things like browsers doing it on their own without explicit direction from the user to do such a thing. And until such time that sni are not in the clear - its pretty pointless anyway. Its more of companies to draw dns traffic to their services and circumvent filtering on the local side.. Its all really bad news if you ask me.. I block that shit for sure.. And also not a fan of applications or devices doing any sort of hard coding of which dns to use even if just normal udp 53, A device or application should use what is set on the the device or parent OS be static or via dhcp - period!! If stuff like browsers want to offer doh or dot as an option - great do that.. But you better not do it without explicit freaking permission from the person running the running the browser.. I don't care how stupid you think the user is ;) You shouldn't be doing anything other than using what the OS says to use for dns without specific OK and setting from the operator of said software..

@kidwell220 When you connect it to the switch do you see it come up with link, do you get lights? What speed does it come up.. While its rare - have seen issues with specific nics and switches, etc. But if you sniff or watch the log on pfsense - if it doesn't see the discover/request - there is nothing it can do.. So this is first thing to validate - that pfsense is indeed seeing the request/discover - and what does it answer? Maybe the switch is dying - if your saying works fine with port X and downstream switch 2.. Plug this device into that port.. Does that work?

@schneizel1208 Not really. The dyndns scripts use a classic 'curl' call - this simulates a web browser request. The answer comes back as the return header, that should indicate "Response Header: HTTP/2 200" where "200" means : all ok. "401", a well error result, indicates : the page you requested doesn't exist on the server. Check the /etc/inc/dyndns.class - line 575 and afterwards. This is this part of the 'code' where noip and noip-free is handled. This is the URL : https://dynupdate.no-ip.com/nic/update To this URL are you added your user credentials. You can use this URL in your browser : I saw : [image: 1632134905550-1d0406c7-2a5b-456e-8a2a-225d58ec4602-image.png] Keep in mind : if you - or some automated scrypt like dyndns.class, visits dynupdate.no-ip.com to often then that is considered as 'abusive' and your IP is blokced by their firewall. You couldn't connect to "dynupdate.no-ip.com" any more for a while. That would explain your issue. Use another IP(WAN) and retest https://dynupdate.no-ip.com/nic/update

Ok, it does the trick. I guess it will be ok for what I have to do. Thanks.

Awesome, thanks. Do I need to do anything like flush the DNS cache by restarting unbound?

this seems to have done the trick! I haven't gotten any watchdog alerts since toggling off Register DHCP leases in the DNS Resolver. thanks again!

I've come up with a solution (I hope!) I've created a subdomain on the domain that I have a wildcard certificate for. This is set to the IP address of the interface. i.e portalabc.domain.co.uk > 192.168.200.1 I'm not really fussed about anyone trying to visit portalabc.domain.co.uk outside of the network. I did notice though, using either the DNS Forwarder or Resolver on the admin LAN, I have to add it as a host override, otherwise ping returns "host not found" for a subdomain pointing to an rfc 1819 IP. Is this setup likely to cause issue somewhere?