Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 1 subscriber
  • Views 2485 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

[5.010] Content Could Not Be Loaded - New Issue

OfficeDefender
We have an internal web/mail server and after loading 5.010, anytime you try to access this site from the INTERNAL network using the FQDN (which resolves to the IP on the external interface), the following error occurs.  The only way to access the site is to use the internal IP address.  What's going on here, folks?  See below.

-Steve


Content could not be loaded    
          
          
      Please check the spelling of your URL.
Make sure that your proxy settings are in order.
The following lines may provide some additional information to the cause of the failure.

TcpSocket.cpp:119:connect:TCP Connect failed to mail.reedelectronics.com:80 (65.86.229.34)


This thread was automatically locked due to age.
Parents
  • 0
    the firewall does not see your server. keep in mind that the DNS of the firewall is the one defined in the DNS proxy.If he is resolving the DNS name to an external IP you should maybe add a second internaly used DNS name for this machine which resolves to an internal IP.
  • 0 in reply to Vukasin
    Vukasin, there are a couple of things to note here.  One is that this situation did not occur in v4.x.  Second, we don't run an internal DNS and simply have the firewall forward all queries to our ISP's DNS servers (or the root servers by keeping the DNS entry blank in the proxy).  

    So the sequence of the error is as follows:  a user on our internal network tries to go to "mail.reedelectronics.com" in their browser, the FQDN is resolved to the IP of the firewall's external interface, but all they get is an error instead of the web page.  Why is this behavior suddenly occurring -- this did not occur in v4.

    Steve.
  • 0 in reply to OfficeDefender
    do the packetfilter rules allow the connection to the firewalls external interface? the error you recieved is telling you that this IP is not reachable. this looks loke an issue in the packetfilter ruleset.
  • 0 in reply to Vukasin
    Yes.  The same rules are in effect that existed in the v4.x installation, which was imported into version 5.  On the external interface, there is a DNAT rule that sends a HTTP request from "ANY" to the internal webserver.  In addition, there is a packetfilter rule permitting "ANY" of type "HTTP" through to the webserver.

    The problem is that from WITHIN the network, those rules don't work anymore.  This issue isn't limited just to our office -- we're seeing the exact same behavior on another network we manage that also has an internal webserver.

    Just for fun, I went on ahead and created a packetfilter rule that allowed the Internal Network to send packets (any) to the External address.  That didn't help.

    Steve.
  • 0 in reply to OfficeDefender
    Your situation is a good illustration of how it would be nice if Astaro's DNS proxy supported simple network host definitions (in other words, make an exception to it being only a forwarder...); when you make a network definition, maybe a checkmark option that says "publish in DNS..."

    Are your masquerading rules correctly recreated?
    With all ICMP firewall options enabled, what does a traceroute/tracert to the FQDN show??

    That's a tricky one: OK, it masquerades it on the external interface; then will the interface immediately turn around and DNAT the packet back in??

    Just for laughs, add Allow Rules for

    Internal HTTP External_Interface
    External_Interface HTTP External_Interface
    External_Interface HTTP Internal_web
    Internal HTTP Internal_web

    I know you've already tried some of these to no avail, but I am just shaking it to see what comes loose and making sure that all permutations were done...
  • 0 in reply to SecApp
    The masquerade rule was imported fine.  As you suggested, I did a traceroute on the FQDN and it's just one hop, straight to the external interface of the firewall.

    You have a good point that it may be helpful if the DNS proxy could support some network host definitions, but the greater mystery here is why this worked just fine in 4.x but it's not in 5.x.  I'm hoping that this is a bug, not a feature.  [:)]

    Steve.
Reply
  • 0 in reply to SecApp
    The masquerade rule was imported fine.  As you suggested, I did a traceroute on the FQDN and it's just one hop, straight to the external interface of the firewall.

    You have a good point that it may be helpful if the DNS proxy could support some network host definitions, but the greater mystery here is why this worked just fine in 4.x but it's not in 5.x.  I'm hoping that this is a bug, not a feature.  [:)]

    Steve.
Children