Too early to say. Probably a long time, we are finishing up 2.4.4-RELEASE right now, and haven't formally started on 2.5 in any way. It likely isn't going to be next after 2.4.4 either.

Ugh yeah, I know Realtek is crap. It worked for years up until recently though, it's like the latest BSD pfsense kernel driver just sucks exceptionally worse for Realtek. This card is pushing a crapload of traffic though because I have an NTP node running behind it. LAN side is running LACP on a dual port Intel with no issues. I do have a free port on the motherboard though, I may find another cheap Intel card off ebay and be done with it.

@mrpeterson Yes, it's a small case business class desktop computer. However, I bought it a few years ago and found it in a store flyer. I don't have a link for it. Regardless, it doesn't have that encryption support I mentioned, so I will have to replace it in the not too distant future.

@tim-mcmanus Couldn't agree more. At its core Tor is just a couple of proxies; a couple of ISP's to "strong-arm" and they've got you. I'm attempting to implement some security practices that make it a lot harder. More specifically 2 end-to-end encryption tunnels (via 2 different "reputable" VPN's and hopefully one of the Raspberry PI devices that turn a tor connection into a network connection, essentially meaning that I will have 8 hops rather than 3. The data itself is rarely ever sensitive in nature.

There is no command that will query the local database users in that way, you'd have to write your own script. You could use the changepassword script as a starting point. It is in /etc/phpshellsessions/ and you run it from ssh or console shell with pfSsh.php playback changepassword for example.

About what I figured. Thanks for the excuse to buy a new box!

Good to hear - yeah pfsense doesn't do anything with the traffic other than nat it.. Unless you were using proxy software pfsense doesn't modify anything.. When you get a new IP from your ISP you never know what the guy that had it before was doing ;)

Are clients able to pull a DHCP lease from pfSense on the LAN or Wifi? Do they appear in the pfSense DHCP status page? If you are unable to ping the pfSense LAN interface by IP then you have a fundamental issue. Try running a packet capture on LAN to see of those pings are even arriving. The description of the issue here could easily be a rogue DHCP server on your network. Steve

Thanks

@jimp Yeah, you're right. Thank you very much. Have nice day, Gabriel

Many an accesspoint/wifirouter will not allow remote admin. When your not from the local network you would be "remote" so you would have to enable remote admin. What is the make and model of this AP?

I finally got the above scripts running as shell scripts, then using cron to call the script itself. So easy and so basic, it's embarrassing to be posting it to such a learned forum, especially after all these years. :) The main motivation to finally learn how to script this came via adapting scripts to automate ACME's Let's Encrypt SSL certs into my UniFi controller, which I have running on my pfSense box (https://community.ubnt.com/t5/UniFi-Wireless/Unifi-Cloud-key-certificate-installation/m-p/2437833#M312944) Anyway, the basic script to automate adblock hosts file updates is: #!/bin/sh FILE="/etc/adblock" /usr/bin/fetch -q -o ${FILE}.new http://winhelp2002.mvps.org/hosts.txt && if [ -s ${FILE}.new ]; then if [ -f ${FILE} ] ; then /bin/mv ${FILE} ${FILE}.old ; fi && /bin/mv ${FILE}.new ${FILE} && /usr/local/sbin/pfSctl -c "service reload dns" && if [ -f ${FILE}.old ]; then /bin/rm -f ${FILE}.old ; fi ; fi Obviously the file name (FILE) and download source can be easily varied according to need. Simply make the script executable (chmod +x) and then point cron to run it whenever you want.

Hi Steve, while collecting the information for my reply, I think I found the relevant point: Search scope level was set to "one level". Setting it to "entire subtree" seems to fix the problem. Thanks!

The pf antispoof rules that are applied by default should block that traffic anyway and are above the user rules. Something isn't right there. Is that counter still increasing? Did you change the rule previously maybe? Steve

Hi, Access console, use option 8. Type dmesg and look for all hardware the kernel found, typically NIC's. pfSense uses the NIC's the OS (FreeBSD) has found.

@warudo said in Accessing 169.254.2.1:80 on an OPT interface from the LAN interface: I did some digging through the FreeBSD sources. While the blocking of this subnet can be disabled in pfSense and causes it to respond to packets, the underlying FreeBSD TCP/IP stack is hardcoded to not forward traffic from and to it. The relevant part is here. So this seems to be impossible. Of course it's impossible, it's against the RFC to do that. https://tools.ietf.org/html/rfc3927 Section 2.6.2 [...] The host MUST NOT send a packet with an IPv4 Link-Local destination address to any router for forwarding. Section 2.7 Link-Local Packets Are Not Forwarded A sensible default for applications which are sending from an IPv4 Link-Local address is to explicitly set the IPv4 TTL to 1. This is not appropriate in all cases as some applications may require that the IPv4 TTL be set to other values. An IPv4 packet whose source and/or destination address is in the 169.254/16 prefix MUST NOT be sent to any router for forwarding, and any network device receiving such a packet MUST NOT forward it, regardless of the TTL in the IPv4 header. Similarly, a router or other host MUST NOT indiscriminately answer all ARP Requests for addresses in the 169.254/16 prefix. A router may of course answer ARP Requests for one or more IPv4 Link-Local address(es) that it has legitimately claimed for its own use according to the claim-and- defend protocol described in this document. This restriction also applies to multicast packets. IPv4 packets with a Link-Local source address MUST NOT be forwarded outside the local link even if they have a multicast destination address. As @stephenw10 said maybe if you had a VIP on WAN in 169.154.x.x and you did NAT to that on the way out it might work, but it would likely still fail to be carried properly since the original host is violating the RFC by sending 169.254.x.x traffic to a router when trying to connect. I would not use a gateway or route-to on traffic to or from 169.254 -- See https://redmine.pfsense.org/issues/2073 for why. What you might need is inbound NAT on the LAN of pfSense to map that 169.254 address to something actually routable. LAN host -> destination LAN VIP -> exit WAN outbound source NAT to 169.254.x.x to destination of 169.254.x.x. The link-local stays local, no RFCs would be violated by that behavior (technically).

Makes no sense.. Have you messed with your outbound nat?