BranoI hate VogonsPremium,MVMReviews:
|reply to ZW_Joe |
Re: USG100 - Weird (and frightening) firewall behavior
Some users have reported here that the FW changes do not apply to existing open connections, only to new ones. Your user may have had already established connection when you closed the firewall.
Or some other rule may have let him/her in if you had the FW rules miss-configured.
San Anselmo, CA
Ah, yeah. Thank you. I had read that before, but in my delirium forgot.
I think (fingers crossed) the rules are sound. Between this forum and Zyxel support I feel I have as complete of setup as I can have.
Is there an elegant way to close connections? Or is rebooting the device the only sure fire way?
Edit: I realized I can turn off access on the server as well, but normally I just hit 'Inactive' so I'd rather keep 'all stop' on the USG.
I do not know if its possible or what the command is on USG, but flushing the NAT/Firewall tables should do it.
"Perl is executable line noise, Python is executable pseudo-code."
|reply to ZW_Joe |
You could disable the interface that the server lives on and then re -enable it to rest the connections
|reply to JPedroT |
Flushing the state table
Two approaches come to mind, since the CLI list doesn't seem to have a flush cache (state table) command as my formerly-used Xincom provides in its GUI. One could flush the state table, and only active connections would be re-established. The Xincom state table was 100k, and the USG 50 table size is only 10k, so the USG is more sensitive to pushing the state table limit. Thus, a flush command would be convenient.
Using the CLIv2 manual as a guide, one could use Table 66 commands to create a rule that greatly reduces the session count, and then after it was saved flush the restrictive rule. Check the state table count on the dashboard to see if it works. I would worry about how low the number of sessions can be before one is locked out.
Alternatively, using the Table 192 commands, one could set the session timings very short, and then return them to wherever they were set. (Note that for BitTorrent, the default settings can lead to a very large number of sessions hanging on because BitTorrent sessions are rarely closed properly.) I know shortening the timings work for all sessions that are hanging on and not active. This approach will not eliminate an active session that is using a firewall rule.
Both approaches are more tedious than rebooting.
P.S. After 78 days of uptime, my USG 50 has blocked 1.8 billion WAN to Zywall hits. Beat that, Safariland and Ceradyne!