google captive portal filter with iptables direction

[AFSM AFSM]

Running 7.4 on Ubuntu server 18  2 NIC VM in default gateway proxy mode. For clients that ignore our WPAD (mainly android phones and tablets) we use IPTABLES to forward port 443 traffic to the proxy at PREROUTING to the intercept port.

This works for most traffic except google captive portal internet detection, the clients are determined that there is no internet (the internet DOES work) as they cannot get a proper response from the google captive portal server.  This is the log

2020-06-09 14:16:29	0	-	-	10.4.2.1	204 TCP_MISS	236 bytes	GET	http://connectivitycheck.gstatic.com/generate_204			none	19	0
2020-06-09 14:16:24	241	pupil_web_range	-	10.4.2.1	200 NONE	0 bytes	CONNECT	216.58.213.10:443			clean	43	0
2020-06-09 14:16:24	239	pupil_web_range	-	10.4.2.1	200 NONE	0 bytes	CONNECT	216.58.213.10:443			clean	47	0
2020-06-09 14:16:21	238	pupil_web_range	-	10.4.2.1	204 TCP_MISS	448 bytes	GET	http://www.google.com/gen_204	search_engines		clean	28	0
2020-06-09 14:16:21	0	-	-	10.4.2.1	200 NONE	0 bytes	CONNECT	172.217.169.4:443			none	44	0
2020-06-09 14:16:21	0	-	-	10.4.2.1	204 TCP_MISS	236 bytes	GET	http://connectivitycheck.gstatic.com/generate_204

As you can see, I added the connectivitycheck.gstatic.com to the squid exclusions and it is listed green.  I even added the IP to the exception with everything ticked.  This made no difference.  As a temporary workaround, I added

-A PREROUTING -i eth0 -d 172.217.169.4 -j RETURN

Before my other routing, a kludgy fix but it works.  Any idea how I can get diladele to allow the 204 response to propagate back correctly?

[rafael....@diladele.com]

Hello Asfm,

The green response and 236 bytes sent by the squid means proxy/webfilter did all required to successfully complete the client request.

There is nothing to be done on the server/proxy side.

But:

- the URL used for connection test is HTTP and NOT HTTPS

- you seem to redirect only HTTPS traffic (port 443) by ip tables if I read your message correctly.

Are you sure the *redirected* port 80 is also handled correctly?

Any host header forgery errors in the squid cache log?

Best regards,

Rafael

[AFSM AFSM]

yes, port 80 is also redirected to teh HTTP interecept port.  I think I need to dig a bit deeper and see what is being returned.  I'll look for a way to trace manual calls to those addresses on an android device - I have a rooted device to play with.  For now, the kludgy fix will work.

[Rafael Akchurin]

If you could make the capture on the proxy side when that device detects the connection - https://docs.diladele.com/faq/general/tcpdump.html

Please share it as I am interested why it fails too.

Best regards,

Rafael Akchurin

Op 9 jun. 2020 om 16:49 heeft 'AFSM AFSM' via Diladele Web Safety <web-s...@googlegroups.com> het volgende geschreven:



--
You received this message because you are subscribed to the Google Groups "Diladele Web Safety" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-safety+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/web-safety/d321cc30-956f-4f42-9e49-2d2c4cb9a150o%40googlegroups.com.

[austinfria...@googlemail.com]

Just a follow up in case others are reading.  We scrapped chromebooks in the end.  They were too much trouble, their methods of proxy authentication is a little odd and would need too many authentication bypasses to work effectively.  Other filtering companies have hit similar issues and have bespoke authentication apps for android.  The cost saving on chromebooks would be eaten into with other filtering packages so we are sticking with Diladele and not bothering with chromebooks.