Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Website inaccessible from intranet 1
- Thread starter sborsos
- Start date
modellbilder
Technical User
I'm having the exact same problem as well. While the external IP that I'd set up on the Firebox does "appear" on the Internet, and I am able to NAT to a server on the trusted side of the Firebox, I am unable to loopback from a LAN host to access the WAN IP.
I've looked at the various services established in my policies manager, but there's nothing obvious that allows this roundabout traffic from within the LAN.
Should I relocate the server to the Optional segment of the network?
I've looked at the various services established in my policies manager, but there's nothing obvious that allows this roundabout traffic from within the LAN.
Should I relocate the server to the Optional segment of the network?
-
1
- #3
modellbilder
Technical User
The public IPs are configured via 1:1 NAT.
Guest_imported
New member
- Jan 1, 1970
- 0
chances are your 1:1 nat is misconfigured
try static nat first you will work
try static nat first you will work
I just realized I think I read your question wrong... You said the pages are hosted internally and they are accesible from the outside. When you attempt to access them from the inside using the public IP it does not work.
This is by design. You need to access them internally via the private IP on the box hosting them. If you have an internal DNS server, be sure to change or add an entry pointing to the private IP.
This is by design. You need to access them internally via the private IP on the box hosting them. If you have an internal DNS server, be sure to change or add an entry pointing to the private IP.
modellbilder
Technical User
Thanks for the clarification, Ntr0P. Do you think it would make any difference if I moved the webserver to the Optional segment (i.e., the DMZ) of the network, at least in terms of LAN users being able to use the WAN address to access the server? Thanks!
If the server is on the Optional, as long as the FB is setup in routed mode, the FB is either your default gateway (or your default gateway knows the IP of the server should go to the FB), and the appropriate services are configured, you should not have a problem.
- Thread starter
- #9
Unfortunately there is not a real good way to tell other than adhering to a naming convention. I use the following: firewallname-yyyy-mm-dd-hh-mm (year, month, date, hours, minutes). This way I know what is what.
What can occur is someone makes a change to the file but doesn't upload it. Thus the date stamp in the file system shows one date, but that doesn't make it the most current file. This can still happen with the naming convention I use, but it is at least a little more intuitive than trusting date stamps.
By default, when you open the configuration policy editor, it will prompt you to save the current running config. using the FB IP as the name. It will only do this however, if the current file on the WCC station is older than the one running on the FB. If they are the same, it will not prompt to save. Therefore, if you are not being prompted to save the file, then the one on your WCC station should be valid.
Sorry for the long answer. Hopefully that helps.
What can occur is someone makes a change to the file but doesn't upload it. Thus the date stamp in the file system shows one date, but that doesn't make it the most current file. This can still happen with the naming convention I use, but it is at least a little more intuitive than trusting date stamps.
By default, when you open the configuration policy editor, it will prompt you to save the current running config. using the FB IP as the name. It will only do this however, if the current file on the WCC station is older than the one running on the FB. If they are the same, it will not prompt to save. Therefore, if you are not being prompted to save the file, then the one on your WCC station should be valid.
Sorry for the long answer. Hopefully that helps.
>My website works fine from the outside, but I can not >access my pages from the intranet using the internet >address. I have static Nat configured.I have 3 public IP >on the Watchguard external, each is redirected to >internal IP's. What can cause this?
got any specific name for this situation ?? why almost firewall got this problem ?
got any specific name for this situation ?? why almost firewall got this problem ?
There really isn't a specific name for this situation though it is a fairly common question. This is not an issue with the firewall, rather it is a design issue within the network. It is a matter of referencing the server with the correct IP address (public or private) when using NAT.
The only firewall I ever encountered that allowed you to reference an internal server by the external address was Guardian v.3.
There are a couple of reasons why the firewall wouldn't allow you to reference an internal server by external address. One is that the inbound NAT rules apply for traffic received at the external interface. Packets would be routed down to the corresponding internal address.
There are a couple of reasons why the firewall wouldn't allow you to reference an internal server by external address. One is that the inbound NAT rules apply for traffic received at the external interface. Packets would be routed down to the corresponding internal address.
- Thread starter
- #15
On the intranet when I enter to the browser, and this address can not be resolved internally, wouldn't it be sent to the next available DNS server on the outside to be resolved, and wouldn't the answer come back with our IP address? (I must be making a naive assumption somewhere)
NTrOP, every time I open WCC, it wants to save the .cfg file. I save it, next time the same thing. I am still not sure which .cfg file reflects what is actually running in the FB. Running tests maybe?
NTrOP, every time I open WCC, it wants to save the .cfg file. I save it, next time the same thing. I am still not sure which .cfg file reflects what is actually running in the FB. Running tests maybe?
sborsos,
You are correct that the DNS request will be answered by another server, but the returned address will still be your public IP and the machine accessing it will still be internal. Thus you are still trying to access the internal server with a public IP from an internal machine which won't work. You can either add an entry to the hosts file for the machines that need it, or add a DNS entry to your internal DNS server using the private IP. If that makes sense. Bottom line you need to know the private IP of the server in order to access it internally.
As for the .cfg file. Does anyone else have access or configure the FB or are you accessing the FB from a different station each time? Either one can cause the result you described. Once you save the .cfg file, you know you have the most current version (filename: <ip address>.cfg).
You are correct that the DNS request will be answered by another server, but the returned address will still be your public IP and the machine accessing it will still be internal. Thus you are still trying to access the internal server with a public IP from an internal machine which won't work. You can either add an entry to the hosts file for the machines that need it, or add a DNS entry to your internal DNS server using the private IP. If that makes sense. Bottom line you need to know the private IP of the server in order to access it internally.
As for the .cfg file. Does anyone else have access or configure the FB or are you accessing the FB from a different station each time? Either one can cause the result you described. Once you save the .cfg file, you know you have the most current version (filename: <ip address>.cfg).
Another thought: if your FB firmware has been updated, the FB will always see this file as a different version due to the difference in the firmware. What you can do is open the policy manager, save the file to disk, and then save it back to the firebox with the new image. This should resolve the issue.
The problem is that the FB can not loopback from a NAT'd to a public back to a NAT'd address. This is by design, per WG. The way we overcame this exact same situation was by implementing DNS internally. This worked beautifully and has actually turned out to be very beneficial to us by allowing us to host multiple internal Intranet sites.
Hi Guys
I have the exact same problem, I have a webserver in my DMZ (optional network) and want to use the same IP from within the trusted network and from the internet. This Server is going to host a lot of domains so it is going to be a huge job to make double DNS admin on all of them. One of my friends claims that he has solved this by creating an alias, but I cannot copy that solution :-(
Are the not any other options to make the public ip's in the DMZ visible from within?
I have the exact same problem, I have a webserver in my DMZ (optional network) and want to use the same IP from within the trusted network and from the internet. This Server is going to host a lot of domains so it is going to be a huge job to make double DNS admin on all of them. One of my friends claims that he has solved this by creating an alias, but I cannot copy that solution :-(
Are the not any other options to make the public ip's in the DMZ visible from within?
Since the FB will not do reverse NAT, you have a couple options. You can do double DNS or you can give all the servers public IP's, disable NAT and place the FB in routed mode.
Using an Alias is similar to the effect a 1:1 NAT solution has. You will still need two DNS entries for this.
Using an Alias is similar to the effect a 1:1 NAT solution has. You will still need two DNS entries for this.
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question