Im running 8.3.1 P05 The firewall is setup as a non-transparent proxy for HTTP and HTTPS applications.
When i use HTTPS as an ip filter (by manually creating a HTTPS application using TCP/443) i get the following: In-band authentication cannot be done on transparent SSL. Session terminated.
When i use SSL (the default application) i get straight-up denied:
2014-03-05 07:47:46 -0500 f_http_proxy a_aclquery t_attack p_major
pid: 11666 logid: 0 cmd: 'httpp' hostname: blah.blah.com
category: policy_violation event: ACL deny attackip: XX.XX.XX.XX
attackzone: internal application: <Unknown TCP> srcip: XX.XX.XX.XX
srcport: 50346 srczone: internal protocol: 6 dst_geo: US
dstip: 184.108.40.206 dstport: 443 dstzone: external rule_name: Deny All
cache_hit: 1 reason: Traffic denied by policy.
Taking out authentication from the rule, i am able to get out just fine.
Using passport authentication, this works! However, the NAT problem is introduced as indicated above.
Using Password authentication, this works! However this is not a viable solution and the NAT problem is also introduced as indicated above.
Using LDAP authentication, i get immediatly denied.
Message was edited by: mathew.d.hailey on 3/5/14 7:18:18 AM CST
Message was edited by: mathew.d.hailey on 3/5/14 7:39:46 AM CST
Is the HTTP proxy set to 'non-transparent' or 'both' in the generic app-defense settings for this rule?
You must add SSL/80 to the ports on this rule or change the settings in your browser to send SSL on port 443 (rather than 80) to get SSL to work non-transparently through the firewall rules (Firewall Enterprise: How to pass HTTPS through the non-transparent proxy (KB70020))
The 'NAT problem' is unsolvable from the firewall's perspective.
Confirmed, the HTTP app defense "generic" is set to "non-transparent" for all the agents (FTP, HTTP, Oracle and Telnet).
I have added the following over-ride to the "internet services" rule: TCP/80 SSL/80,443 (we currently use this configuration on all our firewalls, so i was already familiar with this).
Any other thoughts?
Its unfortunate about the NAT problem, i dont understand why it cant be session based like the LDAP authenticator is.
A few of us here set this up and it worked fine for us. The 'Deny All' audit tells us we are hitting some rule but we can't be sure we're hitting the correct rule. Do you have any other HTTPS rules which interract with this rule (do you have any other HTTPS rule using authentication)? Do you see any auth failures in the audit?
This reminded me of this recent Community post here: https://community.mcafee.com/message/320225#320225
You get a Deny All/Unknown TCP audit when the firewall cannot identify the traffic. Since taking auth out of the rule works we know the firewall is seeing this as SSL/TLS traffic. If a session is interrupted before the firewall can identify the application (such as a request for auth which is denied by the client) then we will see Deny All/Unknown TCP. If the firewall requests auth and we fail the authentication we will see an auth deny audit. If the firewall asks for auth but is RST or FINed we will hit Deny All. That may be what is happening here.
OK..... using your notes about the firewall responses, i was able to figure out what was going wrong.
LDAP is the only authenticator that appears to work behind a NAT. is this correct?