This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

can't load secure pages (https) - gmail.. etc..

I had mentioned this in a few other places, but thought that I would move it to its own thread.

History:

On a small home system with only 7 ip's, it was running fine on 7.101.  I was travelling and logged in remotely to have a look, only to find 2 updates pending that took me to 7.104.  

I never gave it a second thought, so I did the upgrade only to hear from my wife a day later that she couldn't send email, and some pages wouldn't load.

I fixed the email by turning on SMTP and using smarthost to get to my ISP.  

However, I still can figure out why I can't get to any https: site.

In the Content Filter (HTTP) log below, you can see the outbound request.  My browser will ultimately timeout, and in googles case, it returns to a google search of gmail.com.  There are some parts of the log that I don't understand, so feel free to comment if I missed something.

I'm operating in transparent mode, but standard fails as well.

I have no proxy profiles or filter assignments in Web Security.

I have a web surfing group of rules that allow Internal --> Any and these include HTTP (80), HTTP Proxy (8080), HTTP Web Cache (3128) and HTTPS (443).

MASQ is Internal --> External

Is there some other log I should be using?  This fails on 3 computers and the only thing I can relate it to is the upgrade from 7.101 to 7.104.  If I pull the ASG out and connect directly to my Wan port, all is fine.

Mike  [:S]



2008:03:05-13:24:17 (none) httpproxy[23204]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="192.168.1.97" user="" statuscode="302" cached="0" profile="profile_0" filteraction="action_REF_DefaultHTTPCFFAction" size="225" time="144 ms" request="0x81ecc08" url="www.gmail.com/" error="" category="0920" categoryname="Web Mail" 
2008:03:05-13:24:17 (none) httpproxy[23204]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="192.168.1.97" user="" statuscode="302" cached="0" profile="profile_0" filteraction="action_REF_DefaultHTTPCFFAction" size="388" time="144 ms" request="0x81ea430" url="mail.google.com/.../" error="" category="0920" categoryname="Web Mail" 
2008:03:05-13:25:19 (none) httpproxy[23204]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="POST" srcip="192.168.1.97" user="" statuscode="200" cached="0" profile="profile_0" filteraction="action_REF_DefaultHTTPCFFAction" size="757" time="665 ms" request="0x81ea1f8" url="users.conduit.com/.../ Distributors" 
2008:03:05-13:25:19 (none) httpproxy[23204]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="192.168.1.97" user="" statuscode="304" cached="0" profile="profile_0" filteraction="action_REF_DefaultHTTPCFFAction" size="0" time="401 ms" request="0x81e9bd8" url="storage.conduit.com/.../1_Clock.htm" error="" category="1710" categoryname="Uncategorized" 
2008:03:05-13:25:19 (none) httpproxy[23204]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="192.168.1.97" user="" statuscode="304" cached="0" profile="profile_0" filteraction="action_REF_DefaultHTTPCFFAction" size="0" time="405 ms" request="0x81eb638" url="storage.conduit.com/.../1_New.htm" error="" category="1710" categoryname="Uncategorized" 
2008:03:05-13:25:20 (none) httpproxy[23204]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="192.168.1.97" user="" statuscode="200" cached="0" profile="profile_0" filteraction="action_REF_DefaultHTTPCFFAction" size="93" time="771 ms" request="0x81e9bd8" url="www.n0hr.com/.../propstat_hamlinks.php" error="" category="1710" categoryname="Uncategorized" 
2008:03:05-13:25:30 (none) httpproxy[23204]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="192.168.1.97" user="" statuscode="200" cached="0" profile="profile_0" filteraction="action_REF_DefaultHTTPCFFAction" size="54085" time="786 ms" request="0x8246d48" url="www.astaro.org/.../ IT Information"


This thread was automatically locked due to age.
Parents
  • Just one try ... reduce the mtu size of the wan interface.

    Any errors on the wan interface ?
  • I don't think the MTU is it.  I've done a lot of work on MTU and it is set to 1492.  

    If you want some fun, call your cable company and ask them what it should be.  They will tell you to call the vendor of the Router, then they tell you they only support 1 PC connected to the Modem.  So, you say, I will play your game... what is the MTU value for my XP box?  

    Next thing you hear is crickets.... cheep cheep...

    I finally got to level 2, and they confirmed my findings of 1492.

    That being said, if it was a MTU issue, would that not show up with normal web surfing, not just with a secure pages? 

    Also, no errors reported.

    Mike
  • In transparent mode, you have to add a packet filter rule for HTTPS....
  • Thanks....

    I have one for outbound already.  Do I need one for inbound?

    Just to make sure, I did add the rule on its own and not part of a group and no change.  

    Astaro has done this a couple of times where I can figure out why packets aren't flowing for specific service.  As an example, on my first install, MSN Messenger would not work.  I saved my backup to a USB key, rebuilt the box and then reloaded the same settings and it started to work.  

    Sounds like I need to do that again.  The key part is that not 1 configuration setting changed between the upgrade from 7.101 to 7.104 which means we likely have an unfound bug in the upgrade process.  If Astaro is anything like the software company I work for, they don't really test an upgrade procedure, and current versions of the code are tested newly built boxes.

    Mike
Reply
  • Thanks....

    I have one for outbound already.  Do I need one for inbound?

    Just to make sure, I did add the rule on its own and not part of a group and no change.  

    Astaro has done this a couple of times where I can figure out why packets aren't flowing for specific service.  As an example, on my first install, MSN Messenger would not work.  I saved my backup to a USB key, rebuilt the box and then reloaded the same settings and it started to work.  

    Sounds like I need to do that again.  The key part is that not 1 configuration setting changed between the upgrade from 7.101 to 7.104 which means we likely have an unfound bug in the upgrade process.  If Astaro is anything like the software company I work for, they don't really test an upgrade procedure, and current versions of the code are tested newly built boxes.

    Mike
Children
No Data