New 502 Bad Gateway
-
I'm still learning. Can I just enter the two files from reply 165 into the command box via Diagnostics, Command? I am a GUI user.
I have not had any issues yet but following along to prevent any issues. I do use DNSBL and I am on 2.4.1. Was on 2.4 and the related RC's. -
I'm still learning. Can I just enter the two files from reply 165 into the command box via Diagnostics, Command? I am a GUI user.
I have not had any issues yet but following along to prevent any issues. I do use DNSBL and I am on 2.4.1. Was on 2.4 and the related RC's.Use putty as stated here, and when you log in choose shell and copy paste one row after another. Reboot unit and thats it. And use login "root" not "admin" as stated in video.
https://www.youtube.com/watch?v=krNuKDGEjvQ
Cheers!
-
https://pastebin.com/Ek9R0qkh
it starts to become a major issue as well for us. Im about to restore backups..
All virtual firewall's that we upgraded have the same problem…
we have to reboot them multiple times per day to get it working, otherwise ipsec's and openvpn stop working.If that is the output when you have the problem, then it's NOT this problem. No sign of pfBlocker or anything blocking PHP. Start a new thread, it's probably something already solved on 2.4.1 if it's a VM issue. Check the release notes.
since upgrade tot 2.4.1 no problems yet!
-
So far so good with the updated files.
-
I'm still learning. Can I just enter the two files from reply 165 into the command box via Diagnostics, Command? I am a GUI user.
I have not had any issues yet but following along to prevent any issues. I do use DNSBL and I am on 2.4.1. Was on 2.4 and the related RC's.Use putty as stated here, and when you log in choose shell and copy paste one row after another. Reboot unit and thats it. And use login "root" not "admin" as stated in video.
https://www.youtube.com/watch?v=krNuKDGEjvQ
Cheers!
MAC user so I used terminal. Thank you for the point in the right direction, patched this morning after waking up to 502 Bad Gateway.
-
As per jimp's suggestion, please try these two patched files which use a pfSense function called try_lock() as opposed to flock().
Run the following commands to download the patched version of the two files from my Github Gist:
fetch -o /usr/local/www/pfblockerng/www/index.php "https://gist.githubusercontent.com/BBcan177/9f9c8e62b166cee07ad16cd4ff59103c/raw" fetch -o /usr/local/pkg/pfblockerng/pfblockerng.inc "https://gist.githubusercontent.com/BBcan177/7ff15715be0f02afdbe0a00c676aedce/raw"Recommend a reboot after downloading the patches.
You can review the Gist revisions here:
index.php
https://gist.github.com/BBcan177/9f9c8e62b166cee07ad16cd4ff59103c/revisionspfblockerng.inc
https://gist.github.com/BBcan177/7ff15715be0f02afdbe0a00c676aedce/revisionsNote: The try_lock() function calls might require increasing the timeout setting from the default setting of "5" (seconds)
So Far running for more than 24 hrs without problems on pfsense 2.4.0 - I would say it looks pretty good.
I will upgrade to pfsense 2.4.1 tonight.
-
I haven't posted here but have been following the thread as I've had similar issues. After so many hours(less than half a day) pfsense gui and shell would become completely unresponsive even though clients still had internet access.
Replacing the files "index.php" and "pfblockerng.inc" with the ones BBcan177 posted seems to have fixed the issue for me. I've been up for 41hrs now without a problem.
-
Guess I spoke too soon. Just got the 502. Also this seems to stop the firewall schedules from working as a schedule that was allowing access should have been stopped but access was still available. Hopefully it's not affecting other aspects of the firewall security.
-
Is 2.4.1 supposed to fix this without the updated files here?
I saw the redmine ticket was closed due to a new version of pfbng fixing this. Is that automatically installed in 2.4.1? I'm not seeing a package update on my 2.4.1 RELEASE box.
-
If you ran the 2.4.1 update after the new package was uploaded (2.1.2_1) then it would pick up the new files automatically.
-
I still have 502 issue when use pfSense 2.4.1 and pfblockerng 2.1.2_1. :(
-
Still having the issue after 2.4.1, had to disable DNSBL again.
-
Hey all,
Try disabling the Dashboard auto-update check. It seems unrelated, but I made this change last weekend and my system has been stable ever since.
-
I am also experiencing this issue. Error 502 Bad Gateway roughly every 15 hours. Latest version of pfSense and pfBlocker as of the date of this post. I'd post the actual versions but I need to reboot the router to get into the GUI and I can't afford to take down the internet here at this very moment.
As a side note, I've used pfSense for years now and this '502 Bad Gateway' seems to be a reoccurring theme..
-
Running 2.4.1 and 2.1.2_1 and still getting 502 but also getting a few crash reports to send in each day as well.
PHP ERROR: Type: 1, File: /usr/local/pkg/pfblockerng/pfblockerng.inc, Line: 2496, Message: Allowed memory size of 536870912 bytes exhausted (tried to allocate 8192 bytes) @ 2017-10-28 07:02:39 -
Hi,
same here - updates onto last version of pfsene & pfblocker - after about a day it becomes unresponsive.
-
Disabling Snort and it's updates has kept me up and running for 2 days now. I'm going to wait another day and then re-enable snort and see what happens. Perhaps Snort needs the same changes that pfblocker has gotten.
-
I made some additional mods to the code. Run the following command to download the patched version from my Github Gist:
fetch -o /usr/local/pkg/pfblockerng/pfblockerng.inc "https://gist.githubusercontent.com/BBcan177/7ff15715be0f02afdbe0a00c676aedce/raw"Recommend a reboot after downloading the patch.
Please let me know your feedback!
-
For me after 2.4.1-RELEASE (amd64) and pfBlockerNG 2.1.2_1 Finally no more err 502 or 504. Open VPN keep connections.
Sistem running for 2 Days 09 Hours 02 Minutes 23 Seconds. Before i had issues after 6-9 hrs.
Many thnx fo all.
-
Hey all,
Try disabling the Dashboard auto-update check. It seems unrelated, but I made this change last weekend and my system has been stable ever since.
Well it finally failed after a week of being stable…
