On 08/19/2015 07:50 AM, Victor Julien wrote: > On 08/18/2015 02:12 PM, Dick Hollenbeck wrote: >> This is still a problem as of 18-August-2015: >> >> http://vuurmuur-users.narkive.com/1W0jUSnb/existing-ssh-session-being-killed-during-rule-application >> >> I loaded nf_conntrack_ipv4 ahead of time, even logged out and back in, then >> did the >> vuurmuur startup and it killed my ssh connection. >> >> This makes the vuurmuur package unusable. If there is no remedy soon we'll >> have to remove >> this package from our embedded distro. >> >> >> # vuurmuur -V >> Vuurmuur 0.8rc1 (using libvuurmuur 0.8rc1) >> >> Again, its such a disagreeable behaviour that it makes the package unusable. >> > > I wonder what a good solution would be. For example, when you log in > over SSH you can get a env var: > > SSH_CONNECTION=192.168.1.3 34790 192.168.1.1 22 > > If you're willing to trust this env var, you could have the init script > do a work around. E.g. add a rule for that tulpe, or maybe add the > conntrack entry manually using the conntrack tool. > > However, this won't work in all cases. For example sudo strips this env > var away. > > I guess another way would be to have the interface define a 'management' > ip (or port) that operates outside of the conntrack rules (in the raw > table perhaps). > > Suggestions and/or patches are welcome.
Victor, It is useful to experiment outside vuurmuur using iptables-restore and a given set of rules that can be tested. Here is the most simple rules file that keeps SSH alive during the operation: # iptables-restore < rules.txt -----<rules.txt>---------------------------- # Generated by iptables-save v1.4.17 on Wed Aug 19 10:32:04 2015 *filter :INPUT DROP [14:2577] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT #-A INPUT -p tcp --dport ssh -j ACCEPT COMMIT -----</rules.txt>--------------------------- Observations: 1) if OUTPUT policy is DROP rather than ACCEPT, then another rule is needed for that chain. 2) Your chains have policy DROP, (but you knew that). 3) the FLUSH commands will kill any TCP connections instantaneously, and are probably the cause of the problem. I think this even trumps the ESTABLISHED rules that come later. Search this page for "FLUSH is dangerous": http://www.cyberciti.biz/faq/ubuntu-start-stop-iptables-service/ Are you or have you thought about doing this in a two phase fashion? There are several other points of reference to look at, such as the Ubuntu package "iptables-persistent" which is nothing but a script or two. Dick ------------------------------------------------------------------------------ _______________________________________________ Vuurmuur-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/vuurmuur-users
