I think I discovered a possible bug in the ipfilter handling of "block head group", while trying workarounds for the tuning problem [http://www.opensolaris.org/jive/thread.jspa?threadID=42934&tstart=0]
I have problems with two more or less identical Solaris/ipfilter firewalls (Sol10u3 patched up-to-date): Generic_127112-05 modinfo | fgrep ipf 148 fffffffff5db8000 2e888 165 1 ipf (IP Filter: v4.1.9) About 12 months ago after patching Solaris (was 10u3) I got problems with SSH from Solaris/ipf to Linux (Fedora6&7). Ssh worked fine both ways between Solaris and Linux, but if I enbled Xforwarding it would allways hang before I got a prompt when connecting from Solaris to Linux (internal and external), and rsync also tended to hang as well if more than ~2 files were out of sync, same with scp and piping of tar. Solaris to Solaris, Linux to Solaris and Linux to Linux was not affected. I thought it was a Solaris/Linux ssh compatibility bug or a ssh/tcpwraper misconfiguration but never found exactly where it failed. Now, since I lost states due to ipf -T not working properly for some weeks, and ssh tended to be blocked after some minutes I tried a workaround by passing through tcp with "flags A/SA". For some inexplicable reason that solved the problem with ssh from Solaris to Linux with Xforwarding! To dig further into it I've tried to tighten, relax and move the "pass .. tcp .. flags A/SA" up and down the rule set and identified this: This should work (and does with the exception of the strange Solaris to Linux ssh with Xforwardig back or used as pipe for rsync, scp, tar etc): -- block out quick on skge0 from skge0/32 to 10.0.0.0/8 head 40 # from ME pass out quick proto tcp all flags S/SA keep state keep frags group 40 -- This hack does not help: -- block out quick on skge0 from skge0/32 to 10.0.0.0/8 head 40 # from ME to LAN pass out quick proto tcp all flags A/SA group 40 # HACK pass out quick proto tcp all flags S/SA keep state keep frags group 40 -- This hack helps: -- pass out quick on skge0 proto tcp from skge0/32 to 10.0.0.0/8 flags A/SA # Established out hack block out quick on skge0 from skge0/32 to 10.0.0.0/8 head 40 # from ME to LAN pass out quick proto tcp all flags S/SA keep state keep frags group 40 -- I don't understand why, as ssh tunneling is inside the already established tcp-session, so a firewall has (shouldn't have) any clue whether the single ssh 22/tcp-session carries tunnels or not; i.e. part of the point with ssh; it is an encrypted and wiretap-safe carrier of whatever interactive i/o and/or tcp-tunneling you want. Compiling and replacing ssh with latest openssh at both sides did not help. Any idea? Some ssh/tcp-stack flag-defect in either Solaris or Linux/Fedora6&7 that puzzles ipf? This message posted from opensolaris.org _______________________________________________ networking-discuss mailing list [email protected]
