If you want to use nat reflection, just set that up on your nat rule on your wan that redirects 9000 to 3389. If your going to allow rdp from public.. Agree horrible IDEA... and you don't want to remember to use :9000 or not... You could change your rdp to actually listen on 9000 then just port 9000 to 9000 And setup a host override for name.tld that your using to access your public IP outside, to point to the rfc1918 address of the rdp box when your internal. You should really use VPN to access your rdp resources while your outside your network

Thanks a lot for your Input. Somehow I didn't even think about this solution, changed it in the DNS on our DCs and now it's working without a problem. Thanks

I really like the persistence of the shellcmd solution, so I'll stick with that. Thank you very much for your help!

@gouster4 said in 10.0.1.1 to 10.255.255.254 dhcp server pool: Any suggestions? Yeah understand how dchp actually works before you try out nonsense..

You configured it to load external credentials and it worked but then failed to auth at boot? Steve

You could try the FauxAPI pfSense package together with the pfsense-fauxapi Python package that provides both a Python library interface and a command-line interface. FauxAPI package install set fauxapi_base_package_url='https://raw.githubusercontent.com/ndejong/pfsense_fauxapi_packages/master' set set fauxapi_latest=`fetch -qo - ${fauxapi_base_package_url}/LATEST` fetch ${fauxapi_base_package_url}/${fauxapi_latest} pkg-static install ${fauxapi_latest} https://github.com/ndejong/pfsense_fauxapi pfsense-fauxapi client side install pip3 install pfsense-fauxapi https://github.com/ndejong/pfsense_fauxapi_client_python

You might be able to prevent it loading by running at the loader prompt: set hint.i915kms.0.disabled=1 boot Assuming you're talking about the graphics driver. Steve

I assume you have no native IPv6? If you left is configured you ISP may have enabled something that is still broken for example and it's trying to use that in preference. It seems more likely that the remote end point was disabled. I know if nothing that could have changed like that in pfSense base. If you have anything that auto-updates like Snort or pfBlocker that might have started blocking traffic. Steve

There is no way to do that as far as I know. You might suggest it via a feature request on https://redmine.pfsense.org Steve

thanks,

You might want to ask that here: https://forum.netgate.com/category/11/espa%C3%B1ol Steve

@emammadov Enable the TLD option which will Wildcard block domains/sub-domains

@stephenw10 Hi, I saw that too and checked for "SU" and "Su" and only "Internal_Subnets " exists so I have no idea where that came from either. I clearly must have accidentally clicked on on the Wizard at some point in the last few days and not noticed leading it to get very confused. It all seems good now though. Thanks again for your help G

I'm not sure what you're asking me. I personally use squid + squidguard in explicit mode with no SSL interception.

@hasan_ciit said in network subnet access between multiple tunnel: i have pfsense at azure cloud @hasan_ciit said in network subnet access between multiple tunnel: i have zabbix nms at azure Are both those things true? Without adding any additional P2s anywhere or using some sort of proxy at the pfSense site I don't think this is possible. Even with adding one P2 you could NAT the connection on one leg but that would then only allow opening connections in one direction and I believe Zabbix usually requires both. Steve

For VNC viewer to work in a locked-down LAN, you need to allow access from the client on tcp/5900. http://www.uvnc.com/onlinehelp/11.html

Looks like it's 192.168.88.18. I suggest that AP is not configured correctly. Try turning it off and see if that removes the problem. Steve

It may have come from a different subnet. Either way I did end up tracing it down to a faulty DIMM :) Thanks

Mmm, I mean it looks like an ACPI problem, like bad tables. You might update you BIOS if an update is available. You could try running vmstat -i see if that shows a device with high interrupt rates. You can also try booting in verbose mode and see if that shows any useful ACPI errors. Interrupt the boot at the boot loader and then enter boot -v. See also: https://www.freebsd.org/cgi/man.cgi?query=acpi&apropos=0&sektion=4&manpath=FreeBSD+11.2-RELEASE&arch=default&format=html Steve