Static NAT and DMZ hosts not working
Gareth Hinton
How about putting in a static rule (above the other one) for the specific
workstations to the DMZ network which leaves the source address the same.
i.e. The specific workstations will be NAT'd if they are going to all
destinations except the DMZ.
If I understand the question it should work.
Regards,
Gareth
"Daniel Horsley" <dhor...@itupside.com> wrote in message
news:jRJNmjM...@bassett.us.checkpoint.com...
> Hi
>
> I have a basic firewall configuration:
>
> FW-1 4.1 SP2 running on Win2K Adv Server
> 1 DMZ network
> 1 Local Network
>
> Local Network is hidden behind the firewall IP address. Normal users can
> browse to everything perfectly fine.
>
> DMZ has several webservers. hosts that need to, can access everything :
> internet and local network
>
> Problem is this:
>
> a few workstations in the local network require a static nat for another
> application . That works great. workstations can browse the internet and
the
> private IP's of hosts in the DMZ. and the other application works great.
>
> these Static NAT'ed workstations cannot access the public IP's of the DMZ.
> This is a requirement, as our webservers use Host Header resolution to
serve
> several of the websites. Therefore, to successfully test the webservers,
the
> users have to browse to the DNS names, i.e www.somewebserver.com and not
the
> private IP addresses.
>
> They can browse ok if I remove the static nat config, but that is required
> for the other application.
>
> I know that users cannot access the public IP addresses of hosts on the
same
> network, but these workstations and the DMZ are on different
networks......
>
> Please help!!
>
> Thanks
>
>
Daniel Horsley
no static translation.. applied a rule that affected access to the DMZ, but
the firewall still translates it to a public IP address and the process
bombs....
Should I add a second IP address to his NIC and route all traffic to the DMZ
via this new IP address? Would that serve to trick the FW into allowing this
access??
"Gareth Hinton" <ma...@garethhinton.co.uk> wrote in message
news:N7pnxpP...@bassett.us.checkpoint.com...
Gareth Hinton
"I know that users cannot access the public IP addresses of hosts on the
same
network, but these workstations and the DMZ are on different networks......"
The problem accessing the DMZ from internal is that - as far as the firewall
is concerned, the public IP address of your web servers sits on the external
interface of your firewall.
So when your packet goes in to Firewall from internal interface, destined
for the web server public IP address, the Firewall throws it out to the
subnet which exists between your Firewall and your router. There's no way
back in then.
This doesn't fix your problem though.
As a work around, if it's just for testing from limited number of PC's, put
an entry in the 'hosts' file on the PC something like:
10.1.1.5 www.webserver.com
The PC won't go to DNS then, it will resolve directly to internal address.
As far as your current set-up is concerned. I'm not sure quite what you were
getting at with the new workstation.
You only need one object which represents your Web server internal IP
address and one object which represents your web server public IP address.
No more configuration required in these objects at all (other than a subnet
mask)
Perform your NAT translation in the TAB which sits behind the normal
rulebase.
If the line I mentioned last time was the first in the NAT rules:
Source - internal addresses
Destination - webserver public address
Change to:
Source - Original
Destination - webserver internal address
Do a 2nd rule to undo the NAT on the way back:
Source - webserver internal address
Destination - internal addresses
Change to:
Source - webserver public address
Destination - Original
If this doesn't work then there is something I haven't understood about your
config and you may need to go in to more detail, because I'm doing the same
thing all the time.
As always, anybody see any problems with the above, please reply to group. I
welcome any comments which may suggest a better/easier way.
I only know the ways I have found myself.
HTH
Gareth
"Daniel Horsley" <dhor...@itupside.com> wrote in message
news:TKGYJ#xfAH...@bassett.us.checkpoint.com...
Gareth Hinton
Not sure what you;re getting at there.
No need to Translate Source and Destination at the same time in this case.
Translating destination on outbound packet and source on return packet.
Let me know anyway.
Daniel,
I think you'll find things easier if you don't use NAT tab in the object
itself. Try using the NAT Translation tab behind the main policy window.
Sorry if I'm not explaining how to get to it very well. Can't remember the
front tab name and nowhere near a firewall.
It's very possible and easier than you think.
Let me know how things go anyway.
Regards,
Gaz
"Kriby Stickerbush" <ki...@stickerbush.com> wrote in message
news:smZkAv1...@bassett.us.checkpoint.com...
> Check out the articles on Phoneboy.com called "Translating Both Source
And
> Destination IP" and "Can't Talk to Translated IP from Internal Net"
Daniel Horsley
natting and got it to work....
"Kriby Stickerbush" <ki...@stickerbush.com> wrote in message
news:zIwM4$bgAH...@bassett.us.checkpoint.com...
>
> Yeah your right. He needs to do Manual NAT. I was thinking of another
DMZ
> issue where the internal clients try to talk to dmz clients using external
> IP addresses and thinks get funked up because of both being NAT'd.
> Thanks Gareth!
>
> -Kirby
>
> "Gareth Hinton" <ma...@garethhinton.co.uk> wrote in message
> news:Vm3ApmM...@bassett.us.checkpoint.com...