ProxySG & Advanced Secure Gateway

What is the best authentication mode if deployment is transparent via WCCP and authentication is single sign on via IWA-BCAAA? I read the articles below and there are numerous options for transparent setup. Is it also correct that for single sign on, it is best to use IP surrogate? Customer by the way will be intercepting SSL traffic.

https://support.symantec.com/en_US/article.TECH242539.html
https://origin-symwisedownload.symantec.com/resources/webguides/proxysg/6.5/authentication_webguide/Content/Topics/Authentication/Concepts/auth_modes_co.htm

Also, do I have to configure a separate IWA authentication realm for HTTPS authentication? Or one IWA realm should do for both HTTP/HTTPS? Virtual URL is http://<hostname>

Hi Mark,

 

             The best performance optimal authentication mode for Transparent FWD proxy setup would be Origin-IP-Redirect which is based on IP Surrogate. As long as you don't have client machines with shared IP address (NAT, Citrix Farm etc), you can prefer this one for the entire company. Since client is planing to have SSL Interception enabled it will be better to have a realm which is having HTTPS based virtual url for authenticating HTTP and HTTPS requests. So a single realm will be enough to cover both.

Thanks for your quick response! Just one last thing although this is about BCAAA installed on a Windows machine. If the above setup works and the machine where BCAAA is installed and I browse on that machine, is it normal that I get login prompt and I can't seem to get past it using known credentials?

Hi Mark,

 

            Yes, that is a known issue. I couldn't find the article which was explaining the details on this. For accessing internet via BCAAA server, it is better to bypass authentication for that IP.

Got it. Thanks for answering my questions.

Is a Reverse Proxy Service and two IWA authentication realms required for Transparent Proxy Authentication using IWA? Article below included creating Reverse Proxy Service and two IWA authentication realms so I'm really curious. By doing this, sources on Web Access Layer will be two, one for non-SSL and the other for SSL traffic.

Current setup:

Transparent via WCCP
Intercepted External HTTP and HTTPS Proxy Services (ports 80 and 443)
IWA authentication realm with HTTPS virtual URL

 

https://support.symantec.com/en_US/article.TECH242706.html

Hi Mark,

 

                Its is not a must to have 2 realms and 2 RPs for authenticating transparent users. You can set one RP service with HTTPS virtual url and one realm. For HTTP and HTTPS, we can use the same realm for authentication which will inturn use the single RP HTTPS service.

So the Reverse Proxy Service that needs to be created is only for use in HTTPS virtual URL of the IWA auth realm, did I get it right? Then a single IWA realm can be used for HTTP/HTTPS authentication and source for Web Access Layer policies?

Hi Mark,

 

             Yes, you got that correct. Single Realm (with HTTPS virtual url) for both HTTP and HTTPS.

Hi Aravind,

I have another customer that I can't seem to make transparent authentication work. Setup is below:

 

1. Transparent (Virtually Inline) - policy based Routing by firewall (80 and 443)

2. Intercept 80 and 443

3. Added HTTPS Reverse Proxy Service (for HTTPS virtual URL?) with listener ALL source, TRANSPARENT destination, port 4433 and Intercept. Also used self-signed certificate in keyring (for testing)

4. One (1) IWA-BCAAA for auth realm with HTTPS virtual URL (https://<proxy_hostname>:4433

5. SSL Intercept using self-signed certificate (for testing)

6. Web Authentication Layer using IWA and Origin-IP Redirect authentication mode

7. Selected IP in Transparent Proxy authentication menu

 

Now what happens is when a user browses an HTTP or HTTPS URL, the address bar changes to the virtual URL with several characters after the hostname which I assume is query. When that redirect happens, the browser just loaded a blank page. May I know where I made a mistake in the config?

 

Hi Mark,

 

                 The steps you followed here is correct and the re-direct is as expected to the virtual url + some characters (session identification string). I am not able to see a reason for the browser to be blank. Can you try with FireFox browser or chrome and test the access ? Can you post if there is any error page?

Hi Aravind, The error is "This site can't be reached. <proxy_name> refused to connect." Then "ERR_CONNECTION_REFUSED". This is the 2nd computer I tried and using chrome. The browser gets stuck with the error with the https virtual url in the address bar. IE is no different. Just This page cannot be displayed error.

Hi Aravind, The error is "This site can't be reached. <proxy_name> refused to connect." Then "ERR_CONNECTION_REFUSED". This is the 2nd computer I tried and using chrome. The browser gets stuck with the error with the https virtual url in the address bar. IE is no different. Just This page cannot be displayed error.

Using Chrome, error when accessing HTTPS is "This site can't be reached. The connection was reset. ERR_CONNECTION_RESET.

 

When accessing an HTTP URL, error is "This site can't be reached. <proxy_name> refused to connext". ERR_CONNECTION_REFUSED.

Hi Mark,

 

              Are you sure that your firewalls in between the proxy and the client is allowing port 4433 connection. You can run a pcap at client and/or at proxy to confirm this. The messages seems to be related to connectivity

Pcap shows no port 4433. Will there be an issue if setup is using 2 interfaces on a bridge (LAN and WAN)? I configured one gateway (WAN IP's gateway) so traffic for DNS query, authentication, internet is going out WAN interface. WAN IP to BCAAA server is fine. LAN IP to BCAAA is denied in firewall when I tried putting static routes.

Pcap shows no port 4433. Will there be an issue if setup is using 2 interfaces on a bridge (LAN and WAN)? I configured one gateway (WAN IP's gateway) so traffic for DNS query, authentication, internet is going out WAN interface. WAN IP to BCAAA server is fine. LAN IP to BCAAA is denied in firewall when I tried putting static routes.

Hi Mark,

 

               That shouldn't be a problem here. Since you are not seeing any traffic on port 4433 at proxy side, probably client traffic is not reaching here. Did you checked this by taking a packet capture at client side ? Also confirm whether the hostname of proxy is correctly resolved to its IP address at client side.

I managed to resolve some of the issues (customer added firewall policy, change reverse proxy listener destination from transparent to explicit, disabled bridge mode (response is too slow for some reason) and WAN interface, change gateway to LAN gateway IP) but browser doesn't recognize self-signed certificate and it still requires to manually proceed/accept the certificate. Error on certificate is ERR_CERT_COMMON_NAME_INVALID. Was able to find https://support.symantec.com/en_US/article.ALERT2339.html explaining the issue. Since I'm using reverse proxy for transparent HTTPS authentication and customer seems to be thinking of using self-signed cert in the meantime, is there a workaround for this?

Hi Mark,

 

             Trust and validation of certificate used for Authentication is a challenge here. In your case, the validation is breaking as the cert which is now used for HTTPS RP (the same cert you are using for SSL Interception) is not matching with the hostname in the virtual url. Since customer is planing to use self-signed certificate for the time being, its better that you create a new keyring on proxy with the CN (Common Name) matching that of the virtual url. You can then use this certificate in the HTTPS Auth RP service. This certificate can also be pushed to all the clients for trust along with the SSL interception cert. Once this cert push activity is completed, you should be safe.

For SSL Interception, keyring used uses the hostname of proxy as CN. This has been the setup since last week. Now I created a new virtual URL and asked the customer to create a DNS entry for it. That has now been applied only in RP HTTPS proxy service and both certificates are now added in the web browser's Trust Root Certification Authorities. I still get certificate errors. See updated setup below.

 

SSL (Proxy) Interception keyring - uses proxy hostname as CN

HTTPS Auth RP service keyring - uses new DNS entry

HTTPS Virtual URL - uses new DNS entry and port 4433

 

I tried switching the keyrings' usage above but also still getting certificate errors. I even added the certificates in CA Certificate List's browser-trusted. My head hurts just figuring out what I did wrong. LOL

Hi Mark,

 

             Certs can be bit painful :). Is it possible for you to get a screenshot of the browser window where the url and the cert error is shown ?

Chrome, when Advanced is clicked in the cert error message, states "This server could not prove that it is <virtual URL name>; its security certificate does not specify Subject Alternative Names. This may be caused by a misconfiguration or an attacker intercepting your connection."

 

Firefox, meanwhile, states when Advanced is clicked on the certificate error message, "The certificate is not trusted because it is self-signed."

My configuration surprising works in Internet Explorer.

Ohh ok. Got the issue.

In Chrome, there is new restriction added by Google (in the name of security) to check SAN (Subject Alt Names) in the certificates of the webserver. Self-signed certificate in proxy don't have SAN added and hence you have this issue. Ref the link for understanding the need of SAN https://www.thesslstore.com/blog/security-changes-in-chrome-58/

 

For FF, the certificates are not yet added to trusted list. FF uses its on CA Cert list and will need to add the certs manually there too.

I apologize if we're already way off topic but basically you're saying that self-signed certificate will no longer work in Chrome and Firefox because it cannot specify SAN when creating the certificate? I installed the certificate on Firefox yesterday before testing so I was using ProxySG's self signed certificate when I got that error. But I think it worked (Chrome and Firefox) when in Explicit mode last week. I'll retest it later.

Hi Mark,

 

             I know for sure that Chrome will cry about the missing SAN part in Auth virtual url. I have dealt with couple of cases with that and then requested customer to use openssl to create a self-signed certificate externally by including SAN as well as Key-Usage extension (for FF). Issue with chrome is the similar to what is mentioned in article https://support.symantec.com/en_US/article.ALERT2339.html . For the FF issue of Inadequate Key Usage refer https://support.symantec.com/en_US/article.TECH243615.html

Thanks, Aravind! Transparent HTTPS Authentication is now working. Customer decided to sign the CSRs for SSL interception and HTTPS Reverse Proxy/HTTPS Virtual URL. SubjectAltName isn't required for CA-signed certificates, is that right?

Hi Mark,

 

              Happy to hear that. CA certs are not need to have SAN for the time being :) . My current recommendation for customers on virtual url cert is SHA256 + SAN + KeyUsage.