Redirect Public IP to Private IP behind the Pix firewall.

I have a problem, I have a PIX 520.

I have a Public IP which is static to a Private IP behind the PIX (A web server). Everyone outside the PIX can access the Public IP fine. Everyone Can Access the web server by Private IP fine, but when I try to use the Public IP behind the PIX it does not work.

Is there some kind of thing I can do to get users behind the PIX when they request a a Public IP, The pix would say, oh this is static to a private ip.

Any help would be great. I have tried to use the alias command but it didn't seem to work.

Reply to
Samir
Loading thread data ...

In article , Samir wrote: :I have a problem, I have a PIX 520.

:I have a Public IP which is static to a Private IP behind the PIX (A :web server). Everyone outside the PIX can access the Public IP fine. :Everyone Can Access the web server by Private IP fine, but when I try :to use the Public IP behind the PIX it does not work.

You can't do that on a PIX 520, and you will never be able to do that on a PIX 520. (PIX 520 will not be supported in PIX 7.0).

:Is there some kind of thing I can do to get users behind the PIX when :they request a a Public IP, The pix would say, oh this is static to a :private ip.

No. You cannot do this without adding additional equipment.

Note: the limitation is at the IP level. There are several strategies you can use if what your users are doing is requesting a host *name* and the issue has to do with the DNS response that is coming back has the public IP instead of the private IP.

Reply to
Walter Roberson

Thanks for the Reply, I wasn't even sure that was possible either, just wanted to see what everybody else thought.

So what would be the replacement product for the 520? What do you think of the SonicWall and Watchguard?

Reply to
Samir

In article , Samir wrote: :So what would be the replacement product for the 520? What do you :think of the SonicWall and Watchguard?

What are your functional needs?

Reply to
Walter Roberson

Why are you using hard coded IP addresses instead of host names which could resolve to different addresses depending on the request coming from the inside vs. the outside?

Reply to
Rod Dorman

For some reason the pix has a problem when a static a IP for the webserver when using the public Ip behind the firewall. So what I ended up doing was setup IPCOP and used that to forward the Public IP to the private IP and now everyone behind the firewall can get access using the PUBLIC IP of the web server, Must be some setting on the PIX or something.

I mainly want to use the a firewall as to stop all incoming traffic except for certain ones that I specify. Basically just keep out unwanted traffic requests. I see sonic wall is able to do a firewall, anti-virus, spam and much more all in one box.

Reply to
Samir

In article , Samir wrote: :For some reason the pix has a problem when a static a IP for the :webserver when using the public Ip behind the firewall.

I can't think of any problem like that at the moment.

I checked the archives, but you've never posted anything to the comp.dcom.sys.cisco newsgroup before. There has been a Samir (firstname or lastname at different times) before, but not often, and none posted about PIX.

I checked around a bit thinking that perhaps you had posted about the problem in a different newsgroup. You have, uh, an interesting posting history, but none of it appears to be about PIX.

Anyhow, if you post more information about the problem you were encountering, we might have a solution.

Reply to
Walter Roberson

I don't post much, I don't think I ever posted on the cisco newsgroup before though.

I pretty much solved my problem by adding another firewall, so that works for now.

I will try to diagram the problem I guess.

Internet ---->cisco router ---> Pix firewall (205.204.203.202 to

192.168.0.100, I used static and conduit permit)----> web server

The diagram above shows when someone from the internet request a document from the web sever, with the Web server's legal IP address. Everything works fine from this point.

users ---> web server ---> pix firewall (205.204.203.202 to

192.168.0.100, I used static and conduit permit)---> cisco router --->

internet

Now the diagram above shows users behind the firewall when request a document from the web server. Now when the users request a document from the web server by the private IP, it works, but when the users request the document by Internet IP it does not work.

I ended up just installing an IPcop firewall for it's main use for the web server and now everything works for now. Do I need to add anything besides a static and conduit permit for the users to have access to the Internet IP?

Reply to
Samir

In article , Samir wrote: :users ---> web server ---> pix firewall (205.204.203.202 to :192.168.0.100, I used static and conduit permit)---> cisco router --->

:internet

:Now the diagram above shows users behind the firewall when request a :document from the web server. Now when the users request a document :from the web server by the private IP, it works, but when the users :request the document by Internet IP it does not work.

But why do you need to support users using the public IP from the inside? In -most- cases it is enough to have the users use the host -name-, and configure the PIX in conjunction with the DNS servers so that the inside and outside are told different IP addresses when they ask for that -name- [this is fairly simple to set up on the PIX.]

:I ended up just installing an IPcop firewall for it's main use for the :web server and now everything works for now. Do I need to add anything :besides a static and conduit permit for the users to have access to the :Internet IP?

To have access from inside or outside?

Checking back, I see that you are running a PIX 520, and you mention here that you are using conduit. Which particular PIX 4.2, 4.3, or 4.4 release are you running?

Reply to
Walter Roberson

I am sure its Pix 6.3(3)

The reason I need to use the public IP is because the I am using another Web hoster which runs the web page, and the download things are on my server here, I think this might clear it up a little.

So I need the Public Ip because that's what I use on the Web Hosting site to tell where my downloads are.

Reply to
Samir

In article , Samir wrote: :I am sure its Pix 6.3(3)

But you are using 'conduit'. You wouldn't use 'conduit' on PIX 6 unless you were required to by matters outside your control (e.g., certification requirements for a NASA flight simulator.) As you appear to have the authority to reconfigure your PIX 520, we know that's not the situation at hand.

Cisco replaced the functionality of 'conduit' in PIX 5.0(1), and by 5.1(2) was already suggesting that it not be used. By 5.2(3) they declared it deprecated, and by 5.3(1) Cisco started marking conduit-replaced problems as "Won't Fix". Then in PIX 6.2(1), Cisco rewrote important portions of access controls, and anywhere that conduit functionality did not fit smoothly in, Cisco just left conduit broken. By the time of 6.3(1), Cisco had already said clearly that conduit will definitely not be supported in any form in the next major software release (and sure enough, now that PIX 7.0 is released for some models, there is no conduit remaining.)

Thus, by PIX 6.3(3), you are walking the twilight borders of conduit, where things are neither real nor unreal, and debugging nightmares are to be routinely expected.

:The reason I need to use the public IP is because the I am using :another Web hoster which runs the web page, and the download things are :on my server here, I think this might clear it up a little.

:So I need the Public Ip because that's what I use on the Web Hosting :site to tell where my downloads are.

You must have DNS for your public page. Add another hostname to that structure, such as download.son-of-dlx.com and use that on the public pages instead of a literal IP. Once you have the address in hostname format instead of IP format, then the PIX can handle the translation details for you, giving you the appropriate inside or outside address. [The exact configuration details depend upon where the DNS server is relative to the PIX inside.]

Reply to
Walter Roberson

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.