Cisco PIX 501 Port-forwarding

[CubanCorona]

I configured my 501 to forward inbound traffic to the outside interface to a host on the internal network:

access-list out-in permit tcp any host X.X.X.X eq www

access-group out-in in interface outside

static (inside,outside) tcp interface www 192.168.1.2 www netmask 255.255.255.255 0 0

As expected, internet hosts can access the internal web server just fine. However, hosts on the interal network cannot access the webserver when they request it by domain name (which resolves the external interface ip).

So, what do I need to do here? I suppose somehow I need to redirect traffic on the internal network destined for the external interface ip to the internal server (192.168.1.2)? If that's correct, how do you do this?

 

[azev]

best way to do this is to setup spit dns, or add the local ip address of the web server on the host file of each computer need to access it.

 

[spyordie007]

I wouldnt want to try and manage local host files, an internal DNS server is the ideal solution.

 

[cleverhandle]

I'm with azev and spy - split DNS is ultimately the clean and extensible solution to this kind of issue. But out of curiousity (since I don't know PIX's), couldn't the PIX do some kind of redirection like the OP is suggesting? On OBSD's PF, it would look something like...

rdr on $int_if proto tcp from any to $ext_ip port 80 -> $int_ip

Surely a PIX can do that, right?

 

[Agamar]

The PIX will not let traffic generated inside come back in from outside..

In other words, if the internal (10.0.0.1) client is resolving your internal web server (198.xxx.xxx.xxx) as an external address, then the pix is going to block access to that server. If all the internal clients resolve to an internal IP address (10.0.0.2) for the web server, you will be fine.

I ran into the same thing...and it is just in the later versions of the PIX software that they added that.

 

[azev]

Like Agamar said, only pix IOS version 7.0 and up can route traffic back into its external interface. Anyway, my suggestion is having an internal dns server and setup split dns. Its generaly a good practice having a local resolver anyway.

 

[cleverhandle]

Huh... maybe I'm just not seeing the topology correctly here. It doesn't seem like what I was saying means "routing traffic back into its external interface". I figured it would go something like...

1) Client 192.168.0.1 sends a SYN to 66.66.66.66 (the PIX's external interface - the result of the DNS lookup), port 80.
2) The packet crosses the PIX's internal interface and triggers a redirect rule.
3) The packet is rewritten with destination IP 192.168.1.1 (the web server's private IP), still to port 80.
4) The packet is sent to 192.168.1.1, still from the original source address.
5) The webserver receives the SYN and responds to 192.168.0.1.
6) After that nothing should need to touch the PIX, since it's all on the same subnet.

From what I can, nothing ever needs to touch the external interface, because the rewrite would happen before it gets there. Are you guys saying that the earlier IOS's would balk at step #4?

And again, I'm just curious about PIX's, being that I really only have experience with PF. Split DNS is still the best answer.

 

[RebateMonger]

Originally posted by: CubanCorona
I suppose somehow I need to redirect traffic on the internal network destined for the external interface ip to the internal server (192.168.1.2)? If that's correct, how do you do this?

If you have an Internal DNS Server, then you can create an "A" (or Host) record that points requests to "www.mydomain.com" to the internal IP address of your webserver.

A -- www.mydomain.com -- 192.168.0.2

 

[azev]

Originally posted by: cleverhandle
Huh... maybe I'm just not seeing the topology correctly here. It doesn't seem like what I was saying means "routing traffic back into its external interface". I figured it would go something like...

1) Client 192.168.0.1 sends a SYN to 66.66.66.66 (the PIX's external interface - the result of the DNS lookup), port 80.
2) The packet crosses the PIX's internal interface and triggers a redirect rule.
3) The packet is rewritten with destination IP 192.168.1.1 (the web server's private IP), still to port 80.
4) The packet is sent to 192.168.1.1, still from the original source address.
5) The webserver receives the SYN and responds to 192.168.0.1.
6) After that nothing should need to touch the PIX, since it's all on the same subnet.

From what I can, nothing ever needs to touch the external interface, because the rewrite would happen before it gets there. Are you guys saying that the earlier IOS's would balk at step #4?

And again, I'm just curious about PIX's, being that I really only have experience with PF. Split DNS is still the best answer.

1. host client internal ip addr 192.168.1.2 is translated to pix external ip addr 10.0.0.1 to reach external dns 10.0.0.2
2. dns resolve to 10.0.0.1 and supposedly it gets patted to a local web server ip addr 192.168.1.100.

The client is not going to see the local ip address of the web server, and the way pix ios works prior to 7.0 it will block any traffic going in that generated from the same interface.
This is why before 7.0 you cannot do ipsec on a stick with cisco pix.


I think this is how it works, please correct me if I am wrong

 

[cleverhandle]

Thanks for the info Azev - I'll take further questions to PM's, since this is getting off-topic.

Split DNS FTW!