Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 1 subscriber
  • Views 1350 views
  • Users 0 members are here
Options
Suggested
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

7.4 update broke HTTP access

Vuv
Gosh... I've been using Astaro for what seems like forever and this is the first time I haven't been able to overcome a problem!  After updating to 7.4 I can no longer access my web server from inside our outside the network using the qualified DNS name.  I can visit the server just fine via localhost and the internal IP, but not the DNS.  Entering external IP into browser doesn't work either.  In my attempts to resolve this issue I've tried the following...

[LIST=1]
  • Checked web server (obviously...), and it works great.
  • Verified DNS with my provider, which was fine.
  • Checked firewall rules (haven't changed since before the update).
  • Checked DNAT; which also hasn't changed since the update.
  • Followed the advice provided here and here with no avail (AV directories were populated and changing scanning from dual to single did not work).
  • Set proxy to 8080 (currently set to transparent) with no luck.
  • Created exception rule and experimented with skipping various checks, also with no luck.
[/LIST]

All the posts I've found on this forum suggest an issue with AV and HTTP proxy, but nothing I've tried has remedied the issue.  I'm all out of ideas, can anyone help?  [:(]

- Vuv

P.S. I've also noticed that none of my Site-to-site VPNs have come back up.  Is that related?


This thread was automatically locked due to age.
Parents
  • 0
    Have you opened a case with Astaro Support?  This sounds like something they would like to see.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    Have you opened a case with Astaro Support?  This sounds like something they would like to see.


    No, but I'll do that now and get back to you.

    - Vuv
  • 0 in reply to Vuv
    What if you check then uncheck 'Scan HTTPS (SSL) Traffic'?
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    What if you check then uncheck 'Scan HTTPS (SSL) Traffic'?


    I had tried that previously to no avail, and got the same result trying it again just now.

    I just heard back from Support, they're going to log in via SSH, I'll post again after I've worked with them.

    - Vuv
  • 0 in reply to Vuv
    While waiting for support to see what they can do via SSH, I decided to do a packet capture to see if I could find out what's going on.  What I found was interesting.  Turns out my server is getting the initial request, but MY COMPUTER is sending a RST packet instead of completing the three way handshake with the last ACK.  Refer to the attachment.

    *.100 = my computer
    *.1 = ASG
    *.99 = web server
    67.225.91.40 = my public IP

    What makes this interesting is that when I visit the server directly by typing the it's Internal IP into the browser, it works great.  It's worth noting that since the server is working correctly, I haven't changed any settings on it other than to check access logs, etc (access log reflects only the successful connections I've made using internal addressing).

    Any thoughts?

    - Vuv
Reply
  • 0 in reply to Vuv
    While waiting for support to see what they can do via SSH, I decided to do a packet capture to see if I could find out what's going on.  What I found was interesting.  Turns out my server is getting the initial request, but MY COMPUTER is sending a RST packet instead of completing the three way handshake with the last ACK.  Refer to the attachment.

    *.100 = my computer
    *.1 = ASG
    *.99 = web server
    67.225.91.40 = my public IP

    What makes this interesting is that when I visit the server directly by typing the it's Internal IP into the browser, it works great.  It's worth noting that since the server is working correctly, I haven't changed any settings on it other than to check access logs, etc (access log reflects only the successful connections I've made using internal addressing).

    Any thoughts?

    - Vuv
Children
  • 0 in reply to Vuv
    Okay, so Support logged in, had a look at things, and said that the 7.401 update should fix the issue.  It worked... but only in part as now I can visit the site from the outside but still not from the inside.

    They suggested I create a static DNS entry pointing to my internal webserver for the public DNS.  While I'm satisfied that this fixed the issue (i.e. now we can visit our own site using its FQDNS), it seems to me to be more of a workaround as opposed to a fix.

    If you look at the packet capture I attached in my previous post, you can see that when the request came  back into the network using the external interface, it was forwarded to the server just fine.  Then the server replied and the client machine sent a RST packet.  It makes no sense... anyone?

    ***Update***

    Support got back to me:

    "Good to hear the connection is working.  We have seen this behavior as normal for internal networks referencing their own external address which causes problems because of a double NAT loop.  Essentially the address of the PC gets a NAT to the external IP, then hits the external public address of the web server, DNATs into the server.  Problem is the route logic that the server sees is usually in error on seeing the same public address as both the
    original source and destination.

    To eliminate the NAT loops occurring we use the DNAT static route, or as in V6 for this same issue we can use a full NAT rule which directs traffic to
    specifically use the internal interface address of the ASG when internal or
    HTTP proxy traffic request access to an internal server."