Something very strange just happened
-
I'm running 2.1 (Feb 5 20:22:50) on my Alix 2D13 on my home cable connection. I have a webserver in the LAN that I can access from outside on HTTPS, as well as RDP to it. pfSense web interface IS NOT accessible from outside.
This morning I RDP to the web server from work, and then accessed pfSense from the local LAN. I added (to the top) a rule on the WAN interface to allow ICMP traffic from my work IP (wanted to test monitoring). When I applied the rule, I got this error after few seconds in both the console and as email allert"
There were error(s) loading the rules: /tmp/rules.debug:182: cannot define table bogonsv6: Cannot allocate memory - The line in question reads [182]: table <bogonsv6>persist file "/etc/bogonsv6"</bogonsv6>
I acknowledged the error from the web interface and logged out. I then closed the RDP session and tried to access my https server from work and I was surprise to see the typical pfSense web interface warning when I entered my server url:
Potential DNS Rebind attack detected, see http://en.wikipedia.org/wiki/DNS_rebinding
Try accessing the router by IP address instead of by hostname.I then tried using the public IP address and sure enough I was presented with the pfSense login page! I logged in and triple checked that the rules did not change from what the always have been. I rebooted from the web interface and when pfSese came back up, once again I was able to access it directly from outside and the same error as before flashed in the dashboard.
All the port forwarding to my internal LAN are not working despite all the NAT and FW rules being the same as always. Now I will log in one more time and shut pfSense down until I get home because I'm not comfortable leaving the login exposed to the WAN interface.
-
If you have Bogon blocking enabled on systems with low memory (like ALIX) you'll need to increase the maximum table entries under System > Advanced on the Firewall/NAT tab. I'm not sure ALIX has enough RAM to effectively use the IPv6 Bogons list.
If that fails reloading the whole ruleset is likely to fail.
-
Before you change the number of maximum table entries can you check the current value?
pfctl -s memory | awk '/table-entries/ { print $4 }'
If you haven't changed it, it should be 200'000. IPv4 and IPv6 bogons use around 75'000 entries (but the maximum table entries has to be at least twice that size).
Do you have additional packages installed such as pfBlocker? Otherwise the ALIX should be fine and handle the bogons list without problem.
-
Thank you both for the replies. When I got home that day and rebooted the box I still got the same error and the pfSense login exposed to the WAN. I now updated to the next build (Feb 14 04:25) and everything is back to normal.
For the record the table entries are at 200,000, but I am also running pfBlocker to block inboud traffic from several countries.
My current memory usage, reported by the dashboard, is around 50-60%. Should I increase the table entries to 300,000?
-
The tables used by pfBlocker can be quite large when you block many countries. Both the bogons update script as well as pfBlocker package check that their own tables do not exceed the maximum number of allowed entries, however they do not take into account the total table usage, I'll see if I can get that changed.
If you want both bogons and pfBlocker you will have to increase the limit and test if it works (300'000 is a good start).
-
Ok, I set it to 300,000. How can I test the table usage by pfBlocker and bogons?
-
Ok, I set it to 300,000. How can I test the table usage by pfBlocker and bogons?
Use the following code on the command line to see the total usage
pfctl -vvsTables | awk '/Addresses/ {s+=$2}; END {print s}
or just use
pfctl -vvsTables
and manually check the different tables
Btw: You could try the following patch that updates the bogons update script
https://github.com/bsdperimeter/pfsense/pull/418