Firebox 1000 - Optional network cannot communicate with trusted network via an external address NAT'd to the trusted

Goal:

Make my optional network communicate with a web server on the trusted network.

Problem:

I have a static NAT rule in place that forwards incoming packets, destined for port 80 and the specific IP 199.x.x.x, to an internal web server on the "trusted" interface. I've just come into the job and eventually the server will end up on the optional interface of course, but that is outside of this question.

What I really need help with is connecting to this site from an internal computer. As it stands, anyone on the net can hit the website just fine. But when I try to hit the site from either the trusted or optional network, I get ACK RST packets back and the connection dies.

-------------------------- - Watchguard - -------------------------- - - - - - - - - - - - - 199.x.x.x 10.x.x.x 172.x.x.x external trusted optional

These are my three interfaces. Right now 199.x.x.55 ---> 10.x.x.52, and I poke through just fine from anywhere but internally. I'm on the

172.x.x.x network and am trying to access the website via its 199.x.x.55 IP, and that is where I get the page error (ACK RST according to ethereal). Shouldn't this operate exactly the same way an external client operates since i'm referencing the site via its external IP? All I can think of, is that there is something different going on internally than I think, since all three networks are directly connected.
Reply to
Mike.Centriq
Loading thread data ...

There is a firewall function that is blocking the connection. You can reach the destination, but the destination is telling you to go away.

ACK RST is not a page error. You are not talking to the web server application on the server yet. You are talking to the computer, and it is giving you a connection denial. Running your packet sniffer on the server may provide more details.

Old guy

Reply to
Moe Trin

First, you need to understand that you can't route from the Trusted to the External and then back into the LAN. It just don't work that way with these devices.

What you need to do is setup DNS inside the LAN so that you can create a domain name for your website (such as mysite.com) and then put the Trusted IP address in the DNS A record for it.

Since you should be using some type of DHCP and DNS server INSIDE the trusted zone, you should already be using your LAN (Trusted) DNS server for all your workstations. Just setup a MIRROR of the public records for the site in your Trusted DNS and then use the Internal IP addresses.

So, if your public DNS shows this:

A

formatting link
199.x.x.200 A mycompany.com 199.x.x.200

then your INTERNAL DSN SERVER should show this:

domain mycompany.com A mycompany.com 10.x.x.55 (the IP of the server) A

formatting link
10.x.x.55 (the IP of the server)

Now your local workstations should be point to a 10.x.x.x IP address for DNS (so that they can resolve internal and external addresses properly). If you are running a Windows based network, then you use FORWARDERS to point from the DNS service to the external DNS server and your lan computers point to the internal dns server - no entry for the Public DNS server needed, just the internal one.

When you move the web server into the DMZ you will need to point the INTERNAL DNS to the DMZ address.

If you don't have a DNS server in the LAN, then you need to edit your HOST file.

The FB unit will not "loop back" the public IP.

Reply to
Leythos

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.