Blocking SW Update site, with little in the logs to T/S

statuscode="400" means that the request from the Microlite program was not formed correctly.

Instead of showing a valid URL, we see url="" - the Astaro proxy can't connect if there's no indication of where to connect.

Cheers - Bob

Sometimes Astaro sees something as malformed when it's not.  Especially since you said this only happened after 502.  Put microlite's address is the exceptions area of the proxy(where it skips a/v and other scanning).

Sometimes Astaro sees something as malformed when it's not.  Especially since you said this only happened after 502.  Put microlite's address is the exceptions area of the proxy(where it skips a/v and other scanning).

Yea, should have mentioned that I already had done that, with the same result.  I have a ticket in with microlite asking them what the hostname is.  I have microlite.com in all the exceptions, so my guess is the URL is something else.  Maybe I'll just 'tcpdump' the traffic.

put microlite.com in the content filter exceptions too.

Well, I thought that if I entered .microlite.com that any hostnames with that domain name would work, but I had to explicitly put in 'updates.microlite.com' to the exception list to get it to work.  Thinking back, I did choose 'DNS Host' so, that makes sense now.  Should have chosen 'DNS Group'. :-)

glad that fixed ya up..[:)]

bgarlock, microlite.com should have worked on the 'Exceptions' tab.  From your comment, it sounds like you created a network definition for the 'Transparent mode skiplist'.  That should work also, but only if you don't change from running in a transparent mode.

Cheers - Bob
PS It's unlikely that a "DNS Group" definition for microlite.com would have included the IP for updates.microlite.com, so your solution is the right one when using the skiplist.

microlite.com should have worked as the sub is the same ip as hte parent:

Server:  eccserver.ecc.local
Address:  192.168.255.2

Non-authoritative answer:
Name:    microlite.com
Address:  208.69.32.132


C:\Users\William>nslookup update.microclite.com
Server:  eccserver.ecc.local
Address:  192.168.255.2

Non-authoritative answer:
Name:    update.microclite.com
Address:  208.69.32.132

Hi,

I'm having similar issue with updating firmware to my Sony KDL-XBR9 LCD TV.  I'm running v7.503.  I can't seem to get to Sony update service.  Turn off HTTP proxy works fine.  I have a case open with Sony and waiting for a call back.  I have put sony.com and ssm.internet.sony.tv/DTV/stv/c/STVgetTime in the exception list and still unable to get to the sony update service.  Any help or suggestions is greatly appreciated.

Just found out I have same issue with updating iPhone apps using iTunes.  iPhone apps update shows up, but I can't update.  Turn off HTTP proxy works fine.

Here's what on the log

2010:02:22-20:11:09 swirelesssolutions httpproxy[3388]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="192.168.50.50" user="" statuscode="200" cached="0" profile="REF_DefaultHTTPProfile (Default Proxy)" filteraction="REF_DefaultHTTPCFFAction (Default content filter action)" size="294" time="163 ms" request="0xa5a34648" url="ssm.internet.sony.tv/.../" exceptions="av,auth,content,url,certcheck,certdate,mime,cache" error=""
2010:02:22-20:11:10 swirelesssolutions httpproxy[3388]: [0xa5a34648] ssl_log_errors (ssl.c:41) C: 3388:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:s3_pkt.c:1057:SSL alert number 48
2010:02:22-20:11:10 swirelesssolutions httpproxy[3388]: [0xa5a34648] ssl_log_errors (ssl.c:41) C: 3388:error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure:s3_pkt.c:842:
2010:02:22-20:11:10 swirelesssolutions httpproxy[3388]: [0xa5a34648] ssl_log_errors (ssl.c:41) C: 3388:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:s3_pkt.c:1057:SSL alert number 48
2010:02:22-20:11:10 swirelesssolutions httpproxy[3388]: [0xa5a34648] ssl_log_errors (ssl.c:41) C: 3388:error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure:s3_pkt.c:842: 

Thanks

are you using https scanning?