The NAT routing bug

The only fix I know of is to go to each workstation on the network and put an entry in the hosts file.  You say you've tried this and it didn't work -- make sure that you use the internal address, not the external one, when you do this. 

-Steve

The only fix I know of is to go to each workstation on the network and put an entry in the hosts file.  You say you've tried this and it didn't work -- make sure that you use the internal address, not the external one, when you do this. 

-Steve

No, that does not work for me!
Yes, I did put the internal address of the web server in the hosts file but as I mentioned in my initial post, this did not work.
This is what I did in v4 but alas, this approach is not working in v5.
Can someone from ASL give a heads up on when a fix to this issue might be included in an up2date?

Okay, now I have applied up2date 5.013 which states that it fixes this problem.
Again, not for me!

I am running the HTTP proxy on port 8080. I have an entry in the exceptions for 10.*; (in IE6) to exclude my DMZ from being proxied.
I have two MASQs setup. One from Internal -> External and the other, DMZ -> External.
In front of the ASL box is a NAT router that does my PPPoE and authentication stuff to my ISP. The eth1 (external) address has the IP of the NAT router as its gateway.
As mentioned previously, there is also an entry in the hosts file for the webserver IP address.

What happens:
I enter my website (somewhere.com) into the browser and get an authentication dialog box for my NAT router.

If I turn the HTTP proxy off and disable "use a proxy server" in IE, it all works just fine.

What am I missing here guys?

Now at 5.014 - Still not working . . .

Can anyone give me a reason for this behaviour? Surely others out there are suffering the same problem, not just me.
If it's just me, I need to fix my config somehow.

Any feedback would be nice!

Surely someone can give me a method of accessing my webserver from my internal network.

When you are using the HTTP proxy the name resolution on the client PC does not matter, in fact you can leave blank the DNS server entries in your interface configuration and still be able to browse the web just as long all the proxy settings are correct in your browser (using Standard or User Auth). This is because the proxy is what does the name resolution of the URL found in the header. The reason that when using the proxy you can not get to your website is because you have your DNS proxy settings in the ASL pointing to your ISP's DNS servers or somewhere else and the proxy is resolving the name to the external IP which does not work now, which it did in ASL4. The way that I got it to work is to add in the /etc/hosts file a static entry that points the website to my internal server. This works because the proxy first looks at that file to resolve names and then to DNS. For example I added this to my /etc/hosts file:
192.168.7.1    www.mydomain.com
Now, when I type in that URL it sends me to my internal web content. I have not rebooted my ASL since adding this, so I do not know if this change will stick upon a reboot. If not, a simple script is all that will be needed to append this line to the file. Hope this helps some people out!

[ QUOTE ]
I am running the HTTP proxy on port 8080. I have an entry in the exceptions for 10.*; (in IE6) to exclude my DMZ from being proxied.
I have two MASQs setup. One from Internal -> External and the other, DMZ -> External.


[/ QUOTE ]

1. Browsers: Make sure you not only have the IP of your DMZ server excluded, but you also have the *.domain.name excluded as well.

2. You need a nat rule from Internal -> DMZ 

3. I would suggest you create a (DMZ-Server-Services) group with the services you wish to access on that machine to minimize the ports you open into the DMZ. Then create a packet filter rule from internal to DMZ using that service group. (Try it with "All" services first, then change it to the allowed services)

See how that works, thats what we used to have to do in 3.x and I've kept my settings up till now in 4.022 as I didn't realise it was fixed in 4.x.

Looks like it might come in handy for 5.x till its solved.

Of course I don't have as complex an environment as you with two NAT Devices however it shoudl work.

Try telnetting from a workstation to the IP or domain name of the server in the DMZ on port 80 (or a

Hope these ideas help [:)]

Thanks Adam, I did not think of adding the actual domain names in the exclusions. This did the trick.   [:)]
It was not necessary to create additional packet filter or NAT rules, in my case anyway.