Jump to content

Recommended Posts

Posted

Hi guys,

 

We have a Smoothwall 3 proxy on our BYOD network. It is transparently filtering web access. We have found that it will not pass HTTPS / 443 traffic on BYOD machines. If you go in to the browser on the machine and explicitly enter the proxy in Connections > LAN Settings, you can access HTTPS sites. Remove this entry, and have it work 'transparently', and HTTPS stops. There are no errors or block pages displayed on the BYOD device, it just sits there and eventually times out. Any ideas as to why this is?

Posted (edited)

Under testing, it's a Server 08R2 box. Have tested with IE, Chrome, and FF.

 

Same situation with Mac OS 10.6 / Safari 5.1.7

Edited by iSteve
Posted (edited)
I presume we should set the BYOD DHCP to set option 252 for WPAD pointing to a PAC file? Edited by iSteve
....think I answered my own question
Posted

I've been having a play this morning. We've switched to IP cop in its standard form without Advanced Proxy or any other bells and whistles.

I have created wpad.dat and proxy.pac files, they are hosted on the IP cop machine which is listening on port 80. Telling IE to use this pac file, works. I have then set the hosts file of the IP Cop machine to have wpad > 172.16.0.1, so I can point things to http://wpad/proxy.pac for the file

 

Now...things start to get messy...

 

Transparent proxying is turned OFF so I am forcing things to use the PAC etc

 

I have tried to pass option 252 in the dhcpmasq file, however it seems that Windows machines don't requests this according to the DHCP logs. If you set the Windows machine to Auto Detect Settings, it seems happy. HTTP and HTTPS work.

 

I have a MacBook on 10.6 which ignores everything I tell it to use (auto, pac), but is happy with explicit entries

 

iPhone with iOS6 - unhappy with PAC, doesn't request option 252.

 

Turning on transparent proxy, everything connects on HTTP but not HTTPS - as expected

 

Does anyone have a solution working where BYOD users can get HTTPS sites? Help!

Posted
Transparent proxying/filtering of HTTPS will send an invalid certificate (from the router) the client must first trust as it has to do deep packet inspection (if supported). Basically the destination address cant be read from the connection packet as its encrypted so it has to decrypt and reencrypt data. I don't have a smoothwall but a fortigate so cant really help much more I'm afraid.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...