Delete NAT entry and linked rule, traffic still passes
-
I've got another problem with the 6-18-2010 drop (nanobsd).
Today I deleted a NAT entry and the linked rule that was associated with it. It was a high numbered port (over 30000) that would NAT to port 22 to allow SSH into a particular host on my network.
After deleting the NAT entry and rule, I reset all states on the system.
I could still SSH in on that port!
I've just checked, several hours later. I can still use that port.
What debugging should I do to help with the project before I reboot? I assume that after a reboot the problem will go away, so I'll keep it this way for now.
I just looked, and the references to the old NAT entry and rule is still in /tmp/rules.debug.
-
I ssh'd into my router, touched /tmp/filter_dirty, and the system properly reloaded the rules. Looks like it failed to properly reload the filters after leaving the Rules and NAT screens…
-
Read before posting here.
Its a stateful firewall so that is expected! -
I don't think you understood the bug report. I do read, and search.
I deleted/reset all the states, and was still able to connect through the NAT port that was no longer in the system hours before.
The cause of this issue was that the upgrade from BETA1 to BETA3 wiped out all of the cron jobs (I never modified cron myself in the past). So several important things were missing from cron. Such as the filter_configure_sync job.
-
The cause of this issue was that the upgrade from BETA1 to BETA3 wiped out all of the cron jobs (I never modified cron myself in the past). So several important things were missing from cron. Such as the filter_configure_sync job.
There is no filter_configure_sync cron, check_reload_status runs all the time and reloads the rules when needed. I've never seen cron entries go missing, and there isn't anything that would remove them from the config, if you can replicate that post details. I haven't seen any systems where filter rules aren't properly reloaded, if you can replicate that, post back with details. Your check_reload_status is obviously running and functioning if touching filter_dirty made it reload the rules, and that's the same thing changing any rule or NAT in the GUI does.
-
@cmb:
There is no filter_configure_sync cron
I should clarify after seeing your other thread - when using time based rules, yes there is. That doesn't impact the usual filter reload though that you're referring to in this thread.
-
So, clarification: Did all the standard cron jobs go away between Beta1 and Beta3?
During all of this confusing stuff on my side, my router hung during a reboot and never came up. I don't blame the code, I was messing with something under the covers. So I started with a fresh (non-upgrade) install of June-10-2010 Beta1, and it does have crontab entries by default. My system, after the beta3 upgrade, was missing all of these. I don't know why, but they were all gone.
I'm starting fresh now, and everything is working well, for now, and I'll keep an eye on it. My oldest daughter should be screaming at me within 10 minutes when she loses access to the internet… :P
-
So, clarification: Did all the standard cron jobs go away between Beta1 and Beta3?
No, none of the cron config entries have changed in a long time. Almost all of those are static. The filter_configure_sync one gets dynamically added or removed as needed depending on whether you're running time based rules (if you are, and that cron entry isn't there, it's added. if you aren't, and that cron entry is there, it's removed. otherwise it's left alone). The logic there looks fine after glancing over it, it's possible there are problems I'm not noticing looking through it though.