We recently upgraded our firewalls from 7.0.1.02 ro 8.2.1P03. Since the upgrade we have had issues with SSH and SSH keys. It appears the firewall is sending out its SSH key when users are attempting to use SSH traffic through the firewall. We can remedy this if we use an application defense group that does not contain an SSH application defense. Is there a way to use an SSH application defense and have it work tramsparently? Thanks for any info!
I think you'll find that Sam Liedl's document regarding policy creation in version 8 will probably go a long way to answering your question:-
It indicates that in certain cirumstances (and I beleive that SSH is one of them) if you use particular 'applications' it will always operate as a proxy, regardless of the application defense you choose to apply to the rule. This, I'm guessing, then means that the Firewall will always try and play an active role in the SSH connections and will therefore try to use its own keys.
I suspect that the only way you are going to be able to pass SSH through the Firewall and not have it get in the way is to create a user-defined application running on port 22 and use this in the rule instead.
I've encountered a few issues when using some of the McAfee-supplied application entries and Tech Support's go-to response is to use a user-defined application entry instead.
Hope that helps.
Thats coveres my question. Thanks Phil!
Edit: Also found https://community.mcafee.com/message/241362#241362 to be helpful as well.
Message was edited by: vetterous on 11/14/12 5:43:07 AM CST
I managed to get around this by using the SSH application but creating a generic application defence. This lets you still proxy the connection but does not man in the middle of the SSH traffic abd breaking key authentication. However, this won't work with IPv6 as far as I know.