Unless you have other devices in the actual WAN subnet you need to reach you probably don't want that LANnet to WANnet rule in LAN.
If you want to allow access to only the internet from DMZ I would include pass rules for DMZnet to DMZ address for UDP port 53 and 123 to allow clients DNS and NTP access. Then a deny rule for destination 'This Firewall'.
That would prevent DMZ clients accessing the pfSense webgui and other services using the WAN IP.
Neither OpenVPN or IPSec can do that without any config at the server end. However OpenVPN is far easier. Put all the remote client subnets in one large super-net and set that as the remote subnet in the main server config. Then add client specific overrides for each client site with the actual subnets set.
When you add a nee client you will need to setup a new client login at the server and add the CSO for it.
@stephenw10 I took your advice and opened a ticket and in less than an hour the config backup from the pc was converted, sent back to me, and restored to the XG-7100 (maybe 30 minutes). So very cool! As a plus I am learning a lot from the converted backup file that Vladimir sent to me. Thanks!
You can try that but I don't think it will help. It behaves like some low level mismatch or limitation.
Like for example the TTL limitation I mentioned. If that router only allows a limited number of clients one way they can enforce that is to prevent you using another router behind it.
Port 22, so scp/ssh? Nothing special should be required.
If you are still seeing that same error and the passive ports are open then the server is probably misconfigured and handing out it's internal IP to connect to. And the client is not clever enough to see that and ignore it. The Filezilla client will do that for you.
If you just have ONE Access Point and are not interested in all the charts, logs and graphs that is generated with the controller software, just use the Apple IOS app to install and setup the access point. Since the app is FREE, it's a lot cheaper than the Cloud Key and easier than configuring the controller software.
That's what I did and it works great. You can change IP addresses, update the firmware, etc all from the IOS app.
Mmm, hard to see what we can do here without patching something quite low level.
Ideally we would want it to remain in CARP maintenance until the states have syncd. That would probably need to be selectable though as some people will not be syncing states.
We could probably force the Primary to boot into maintenance mode at every boot requiring manual intervention to failback. It would still failback automatically if the secondary went off-line entirely. Would that be in any way practical for you?
The health feature would be a good idea. Although it's been over a month now and Snort has been stable with-out Service Watchdog, the problems we had with Snort in the earlier versions of pfSense no longer appear to be present.
At this stage I suspect the crash may have been the result of a conflict between Snort and Service Watchdog possibly while Snort was updating.
pfSense its its own operating system that happens to be based on FreeBSD.
You appear to have a FreeBSD system that someone manually configured to be a firewall.
pfSense can't help you get any information from that. You might try posting on a FreeBSD forum for help in tracking down the information you need from that system.