We are using non-transparent proxy using ldap authentication connector. When a user attempts to access a http website via the proxy it works fine. However, when the user attempts to access a HTTPS site, the firewall denies the request. We are NOT intercepting the traffic; we have an exempt all rule for SSL traffic. Switching to the Passport authenticator (with LDAP settings behind it), users are prompted for their password and BOTH http and https works! However it appears to be IP based rather than session based (because users who are NAT'd internally do not get prompted once someone else has logged in behind the NAT). Is there any way to either: (A) make HTTPS work with authentication on our non-transparent proxy or, (B) make the passport authenticator session based so that users behind a NAT get prompted to enter their credentials ?????????
On a side note, it appears as though the firewall is stepping on iteself when using LDAP authentication with HTTPS non-transparent proxy as it stright-up denies the traffic and the protocol is not even identified.
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: 22.214.171.124 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 CSTMessage was edited by: mathew.d.hailey on 3/5/14 7:55:51 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.
Thanks for the breakdown of the firewall responses, this actually helps alot! Actually the Firewall is seeing a FIN and hence the deny all. I will do some more dumps to see where the FIN is originating.
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?