4 Replies Latest reply on May 24, 2012 1:53 PM by sliedl

    Odd behavior from SSH proxy

      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.

        • 1. Re: Odd behavior from SSH proxy
          sliedl

          When SSH is set to <None> it's not going to do the 'special' SSH proxy stuff, yes.  This 'special stuff' entails presenting it's own cert to you (the SSH proxy cert/key) instead of just passing you through.  When you set it to <None> it's a generic proxy (let's say) and doesn't present its own proxy key to you, it passes the server key through to you.

           

          I don't know about that last point, but I'll forward this on to the engineers for their opinion.  I'll try it out also.

           

          Edit:  Yes, I get the same transport negotiation error.  I'll find out why.

           

          Message was edited by: sliedl on 5/24/12 12:08:28 PM CDT
          • 2. Re: Odd behavior from SSH proxy
            sliedl

            Yeah, when you set it to 'Use TCP proxy' and then <None> in the app. defense it's forcing the proxy but it has no 'smarts' to present its key to the client.  It 'should' pass it through like a generic TCP proxy and not error out.  I will file a ticket.

             

            Thank you very, very much for a great explanation of the issue instead of just asking "Does the SSH proxy work?  I can't get it to work sometimes."  It helps a lot, we appreciate it.

            1 of 1 people found this helpful
            • 3. Re: Odd behavior from SSH proxy

              Thank you!  I've just been trying to wrap my head around the complexities of version 8.  I had version 6 and then 7 figured out pretty well, but I've been feeling a bit lost in version 8 with the addition of AppPrism.  You're response to the tech support case/question I opened a few days ago helped clarify that a bit, and lead me to do some more experimentation with the applications and app defenses.

              • 4. Re: Odd behavior from SSH proxy
                sliedl

                Oh yes I did talk to you the other day, that's right.

                 

                We will have more information on version 8 and how it works, I promise you.  I'll take care of it.