[pfSense] SOLVED: check_mk breaks NAT Reflection was: NAT Reflection not working after update from 2.0.3 to 2.1
Hi, Almost everything worked fine, but my NAT Reflection does not work anymore. The NAT Rule itself works, aka. I can access the HTTPS server from the outside. My NAT Role is very simple: Interface WAN, TCP, any source, any source port, Destination is WAN Adresse, dest port https, redirect target to my internal webserver (openssl s_client worked from the FW) and redirect target port https. I tried it with NAT reflection to Enable (NAT+Proxy) and Default. There is a associated filter rule created. The same is done for ssh, but with an a high port instead of 22 on the outside. This is also not working. There are no Floating Rules, and I cleaned the Trafic Shaping, just in case. In System - Advanced Setting - Firewall / NAT - NAT there is no checkbox checked and NAT Reflection mode is set to Enable (NAT+Proxy). I found the problem. The check_mk package uses /etc/inetd.conf instead of /var/etc/inetd.conf and start the inetd without the configfile parameter. Disabling check_mk and rebooting helped. CU Jens ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Alix Update 2.0.3 to 2.1 fails with 11 interfaces (/var full)
Am 12.10.13 00:35, schrieb Walter Parker: Hi, So, if I have an ALIX that I would like to upgrade, how much would I have to increase /tmp and /var by to have the upgrade run to completion without filling the partitions? How many Interfaces do you have. With 5 it is no problem with 11 it is. Can't tell you where the exact speperation is. The problem also occurs when the RRD data is delete before the upgrade, so the empty rrd files are to big, when 11 interfaces are used. I will try to figure out where the limit is. CU Jens ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Alix Update 2.0.3 to 2.1 fails with 11 interfaces (/var full)
Hi, On 2.1 you can adjust the /var and /tmp sizes under System Advanced on the Miscellaneous tab. Right! I had forgot about that. and would not help because it is needed to be done before (or during) the upgrade. So following the original topic, could one more probably ensure a successful upgrade to 2.1 by increasing the size of /var by some amount? I have a nanoBSD system with 4G of RAM sitting at 10% usage. If I dedicated 3G of that to /var and upgraded, will the RRD bug in question still kill my upgrade? I kust did that. I increated it to 2*100MB and now it is enough for my upgrade on my virtual machine. I will do the real upgrade tomorrow, with deletion of the rrd Data before the update and a restore of the rrd-data after the upgrade with the already converted rrd backup. On a related note, does this bug affect upgrades from older 2.1 betas and RCs? This system happens to be running 2.1RC0 and I'd very much like to upgrade it to 2.1 without going on site if I can avoid it. I have a identically setup with ony 4 networks and that works without problem. Only embedded setups with a large number of interface statistics has this kind of problem. CU Jens ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
