I'm doing some testing with our 8.2.1 firewall rules that allow SSH traffic since learning that the SSH application is one of those that will always go through the proxy and not packet filters. In version 7, I had used packet filter rules for passing SSH since the firewall's SSH server listened on those ports. I set up this version 8 firewall cluster to do the same--or at least I thought I did. Those rules that pass SSH are using an app defense group that uses a Generic app defense with none of the "use proxy" checkboxes checked. In addition, the SSH app defense is set to <None>. I can see in the audit log that, as expected (after I learned about this feature of the SSH app), this SSH traffic is still being processed by the SSH proxy.
However, in doing some tests, I found a couple of things I don't understand. When I moved this application to an application group that is used in rules with proxy app defense groups (where "use proxy" is checked for TCP, UDP, and ICMP, and the SSH app defense is set to the Default Proxy version), I received the SSH key change warning from PuTTY when connecting to a server behind the firewall. Why would this change if it was using the proxy before, also? I'm assuming that setting the SSH app defense to <None>, while still using the proxy, turns off all special proxy functions (forces the use of a generic proxy on port 22?).
The next test was to use an app defense group with a Generic app defense set to force proxy use for TCP, but then set the SSH app defense to <None>. This *broke* SSH traffic through the firewall for this test rule, generating this audit log error:
"Transport negotiation not correctly configured. Session terminated."
This is the part I find confusing, although I think I may have figured it out in typing this up. I'm guessing that when I check the box for "use TCP proxy" in an SSH rule, it tells the firewall to use the full features of the SSH proxy (i.e., to use the SSH proxy rather than a generic one on port 22), but then setting the SSH app defense to <None> causes it to fail because it has no configuration information for those features. Is this correct? It's a very subtle thing, if so, and a bit tricky.