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

ASL 5.01 - HTTP Proxy & Webserver in DMZ

I've recently put online a fresh install of 5.01.  nothing has been imported.

The only problem I come across is when the HTTP proxy is running (transparent mode).
I have a couple of webservers sitting in the DMZ, there are entries in NAT/Masquerading that redirect the external IP address to the DMZ address as well as entries in packet filter rules to allow access.
External users i.e. those who access the website from the internet can see the websites fine.
If you try to access the website from the internal network whilst the proxy is running (using for example http://www.example.com) I get the following error:

ERROR

The requested URL could not be retrieved

While trying to retrieve the URL: http://www.EXAMPLE.com/

The following error was encountered:
Connection Failed

The system returned:
    (111) Connection refused

The remote host or network may be down. Please try the request again.

Your cache administrator is webmaster. 

Generated Wed, 28 Apr 2004 19:12:57 GMT by XXXXX.XXXXXXX.net (squid/2.5.STABLE4)

If I turn off the proxy I can get access to the websites OK.

Any ideas?

Many thanks,

Darren  [:S]


This thread was automatically locked due to age.
Parents
  • That usally means the page is down, which it would appear to be from your client sinc ethe server is in the lan, and it's not possible by default to go out from the lan, translate hostname, and then dnat back into the server in the dmz since the packet will contain invalid information.

    You have 4 options for clients in the lan.
    -Add the private, dmz ip of the webserver to a host file on the client workstations
    -Add an entry in the in-house DNS server to reference the privatre IP so the clients are automatically translated there.
    -instruct the clients to access the site via it's private ip.

    Number 4 is a bit more advanced but does work just fine. You need to add an SNAT rule to get around this.
    Add the following SNAT rule:
    Source: LAN(eg 192.168.0.0/255.255.255.0)
    Service: HTTP
    Destination: DMZ Webserver (eg. 10.50.50.1/32)
    SNAT:
    - Change Src. IP To: internal Interface Firewall
    - Change Src.Port To: 'no change' 
    DNAT:
    No entry!

    This will form the packet correctly so the response can be handled by Astaro to refer the information to the correct private ip of the client.

    And finally, dont forget to have a packet filter rule allowing clients in the lan to access the server/service in the dmz.
Reply
  • That usally means the page is down, which it would appear to be from your client sinc ethe server is in the lan, and it's not possible by default to go out from the lan, translate hostname, and then dnat back into the server in the dmz since the packet will contain invalid information.

    You have 4 options for clients in the lan.
    -Add the private, dmz ip of the webserver to a host file on the client workstations
    -Add an entry in the in-house DNS server to reference the privatre IP so the clients are automatically translated there.
    -instruct the clients to access the site via it's private ip.

    Number 4 is a bit more advanced but does work just fine. You need to add an SNAT rule to get around this.
    Add the following SNAT rule:
    Source: LAN(eg 192.168.0.0/255.255.255.0)
    Service: HTTP
    Destination: DMZ Webserver (eg. 10.50.50.1/32)
    SNAT:
    - Change Src. IP To: internal Interface Firewall
    - Change Src.Port To: 'no change' 
    DNAT:
    No entry!

    This will form the packet correctly so the response can be handled by Astaro to refer the information to the correct private ip of the client.

    And finally, dont forget to have a packet filter rule allowing clients in the lan to access the server/service in the dmz.
Children