recently I discovered problems with the Weather-App from my iWatch again. It did not connect to the internet any more and so I factory reset it but it didn’t work either. I know that I have discovered problems with the iWatches sometimes in the past in case the web proxy is configured as automatic.
The proxy on iPFire is non-transparent.
When setting the 17.0.0.0/8 subnet in the proxy configuration page as whitelisted the iWatches seem to work. However, iPhones do not seem to have any kind problems.
This time I wondered why this behaviour happened again from one day to the other. First of all I discovered that I configured the netmask on iPFire incorrectly, and wondering what happened, I afterwards discovered that there do exist a lot of open connections to port 53 (DNS) from various machines though these should be proxied by ipfire.
When sending:
'netstat -a | grep:53'
a quite tiny list is provided. When looking into the list provided by the web interface, a lot larger list is being presented.
There seems to be a huge gap between the information provided on the web interface and the shell. I assume it might be that the web page shows some kind of NATted connections, whereas netstat -a shows different information.
In addition, I wonder what happens with the iWatch, in my words, there must be something that prevents this device from keeping it’s connection to the Apple Cloud (17.0.0.0/8) when it needs to proxy through the iPFire device.
I assume the iWatch tunnels via Bluetooth through the iPhone, then through the iPFire. Anyway, something seems to prevent to keep this tunnel alive. That’s my guess, don’t know if this is correct.
Apologize for editing; I did some deep diving today morning and needed to correct this.
the information shown at connections.cgi are obtained from conntrack and are more detailed than the output of netstat, which explains the connection information delta.
In addition, I wonder what happens with the iWatch, in my words, there must be something that prevents this device from keeping it’s connection to the Apple Cloud (17.0.0.0/8) when it needs to proxy through the iPFire device.
Are you sure those devices/applications are able to deal with proxies? Commercial products usually are not very good in dealing with those, as proxies are less common nowadays, and more vendors take the arrogance of assuming a direct internet connectivity.
I assume the iWatch tunnels via Bluetooth through the iPhone, then through the iPFire. Anyway, something seems to prevent to keep this tunnel alive. That’s my guess, don’t know if this is correct.
Could you search your logs for any related entries? If there are corresponding hits in the firewall section, the device was not using the proxy for some reason. Otherwise, try enable proxy logging and search for denied requests (perhaps a CONNECT on port 80?).
thank you for your response. In regards to your questions, I’ve had a look at the proxy log in /var/log/squid/access.log and when changing the standard location for weather I’d receive the following response:
xx is BLUE. On the mobile the proxy is enabled and everything (apps etc) work so far. The apps on iPhone do work, the “Weather” app and the software update do not seem to work in case of using it without 17.0.0.0/8 whitelisted.
However, it appeared in the past that it did work, for some reason it stopped again after a while.
[Edit1 ] Correction: it works different (again). It seems to work with already selected weather locations, including location based weather services, but not with new ones.
[Edit 2] Anyways, the watch just fell onto the bathroom floor as I took me tee, it ways laying beyond. Seems this task has become now irrelevant, as the display got lose and I need to take it for repair.
FYI. I have had troubles repairing the device by myself (it’s an elderly iWatch), so I need to wait until the other device comes back into the area for testing.