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

Local network unable to view DMZ webpages

Have local network 192.***.***.***, DMZ 10.***.***.***, Public 69.***.***.***, each on a unique interface on the Astaro V8. Have 2 webservers in the DMZ, DNAT public ip to DMZ ip allowing port 80 and port 443. The webpages on these servers render fine to anyone from outside our network but the pages will not render http or https from inside the local network. Other web requests to outside networks work just fine. Can ping the DMZ 10. from the Local 192. Tried ip's instead of names, both 443/80, neither worked. Any help appreciated... Thx, B


This thread was automatically locked due to age.
  • Hi, bernieb, and welcome to the User BB!

    What do you see in the Firewall and Web Filtering logs relative to this?

    Cheers - Bob
  • Hi Bob, thanks for the reply! We are using the Sophos Web Filtering Appliance and I turned off the static policy route pointing all web traffic there in the Astaro to take the web app out of the equation temporarily... (still seeing the same results bypassing the web filter and heading straight out/all outside sites render fine, can't see the ones in the DMZ locally.
    Here is the traffic from the firewall log file:

    2012:08 cc***-1 ulogd[6365]: id="2000" severity="info" sys="SecureNet" sub="packetfilter" name="Packet logged" action="log" fwrule="60021" initf="eth5" mark="0x3000000" srcmac="xx:xx:xx:b:ee:3" dstmac="xx:xx:xx:f0:88:85" srcip="192.168.***.***" dstip="64.220.***.***" proto="6" length="52" tos="0x00" prec="0x00" ttl="128" srcport="50043" dstport="443" tcpflags="SYN" 
    2012:08:21-14:00:08 cc***-1 ulogd[6365]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="6" initf="eth5" outitf="eth5" mark="0x3000000" srcmac="xx:xx:xx:b:ee:3" dstmac="xx:xx:xx:f0:88:85" srcip="192.168.***.***" dstip="10.1.***.***" proto="6" length="52" tos="0x00" prec="0x00" ttl="127" srcport="50043" dstport="443" tcpflags="SYN" 
    2012:08:21-14:00:08 cc***-1 ulogd[6365]: id="2000" severity="info" sys="SecureNet" sub="packetfilter" name="Packet logged" action="log" fwrule="60021" initf="eth5" mark="0x3000000" srcmac="xx:xx:xx:b:ee:3" dstmac="xx:xx:xx:f0:88:85" srcip="192.168.***.***" dstip="64.220.***.***" proto="6" length="52" tos="0x00" prec="0x00" ttl="128" srcport="50044" dstport="443" tcpflags="SYN" 
    2012:08:21-14:00:08 cc***-1 ulogd[6365]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="6" initf="eth5" outitf="eth5" mark="0x3000000" srcmac="xx:xx:xx:b:ee:3" dstmac="xx:xx:xx:f0:88:85" srcip="192.168.***.***" dstip="10.1.***.***" proto="6" length="52" tos="0x00" prec="0x00" ttl="127" srcport="50044" dstport="443" tcpflags="SYN" 


    Thanks,
    Bernie
  • bernieb,

    If you don't mind me asking, what web server(s) are you running in your DMZ?  Do they have any kind of intelligent blocking based on Private IP source addresses?  It's going to be difficult to diagnose with the information you've provided.  The output you've posted above shows that your Astaro has successfully logged and accepted the SYN packet from your machine to the DMZ web server.  I would check other logs to ensure that the request isn't being dropped by another process (IPS maybe?).  Lastly, try to enable masquerading temporarily from Internal to DMZ (thereby NATing your requests as the DMZ interface of the Astaro as source) and see if it alleviates the issue.  Then report back with your findings!

    Thanks,

    Chris
  • The clue in the logfile is "60021" - a NAT problem.  You're trying to access the DMZ server from the internal IP via the public IP in the NAT.  I just saw another of Chris' posts, so I bet he'll be able to explain this better than I, but I think the issue is that the DNAT applies to the INPUT chain, and your packets are in the FORWARD or OUTPUT chain.  But enough gobbleygook...

    Here's the KnowledgeBase article you want: Accessing Internal or DMZ Webserver from Internal Network

    Cheers - Bob
  • Bob/Chris, Thank you both for your help. I think the Knowledge Base article is putting me on the right track to getting this resolved. I have tried both options from within it and although I haven't hit the right combo yet, I think it is just a matter of time... (One of my experiments returned an SSL connection error which was different from what I was getting before and why I think this is pointing me down the right path). Prior to working off the article, I tried enabling masquerade without success and didn't see anything in the IPS log. In the DMZ are 3 boxes, running apache/iis/lansa all on port 443 only. Had a different appliance on this network that had this config working so I have to believe it is in my new config on the Astaro. Anyway, I think you guys have me going in the right direction and I will let you know what the correct combo is when I hit it. Thank you, B
  • Bernie,

    Good luck.  I'm sure you'll get it before long.  Just check to make sure that the URL is pointing to the real address of the web server as Bob's response suggests.  While the knowledge base article is typically correct, it doesn't account for network deployments that aren't set to forward to the firewall for DNS resolution.  So, say you had your own DNS server on site through Active Directory or what-have-you.  Unless the forwarder in that DNS server is set to your firewall (and not your ISPs DNS or Root Hints), adding the static DNS entry that changes the URL of the site to point to the real DMZ IP likely will not work unless you enforce it on the additional DNS server itself.

    So, quick check from a client.  If ping (or nslookup) yourwebserverurl.whatever does not equal 10.X.Y.Z and instead equals a 69.X.Y.Z address then your client is in fact traversing the firewall to reach the External interface only for the firewall to route it back through to the DMZ.  This generally doesn't work from a routing standpoint, much less when using any form of NAT on top of it.  This type of connection is referred to as NAT Hairpinning and I don't think Sophos supports it.  Though quite a few of the SOHO routers you can purchase do.
  • OK, ruhllatio has made me think of a couple other tips.

    There are other good ways to do it with Astaro/Sophos, but DNS Best Practice is one.

    Confirm that none of the Host/Network definitions you've created is bound to a specific interface; always leave them with 'Interface: >'.

    Cheers - Bob
  • Bob/Chris, thank you again for all of your help! During my experiments with the knowledge base info I was able to hit those servers from the local (192) network with ssh, and was able to render http web pages if I replaced the domain name with an IP. Still couldn't hit the  pages via "name" though so it was looking like a DNS issue to me. I stop by the forum and you guys were already one step ahead of me! Messing with the Full Nat options I was able to ping 10. sometimes and 69. at others and I know that I have those names bound to specific interfaces too instead of "any". New plan of attack is to get everything back to square one, take a look at the AD DNS, the Astaro DNS, my client DNS settings and get those host definitions on the Astaro unbound from the specific interfaces. If that doesn't correct it then I will built upon that by revisting the NAT and  masquerade options and see if we can get those names to finally render locally. I think were close [:)] will hopefully report back with some successful results! Thanks again, B
  • Bob/Chris, so this has finally been resolved... It was 1) unbinding the specific interfaces (back to any), 2) setting up the "Full NAT policies" from local to the DMZ, and 3) Static routing of all internal traffic from "local" to bypass the sophos web filtering appliance on any DMZ requests (as there is a static route to puss all http/s traffic through that box. Needed all 3 pieces to be corrected in order to finally get the pages to resolve, but they are now resolving! Thank you again for all of your help! Bernie