Re: Port Translation (redirect) and 515e

brenteads · ‎03-31-2005

Having an odd problem with port redirect. Seems that all traffic being direct to various web sites is defaulting to the first static. Ignoring the rest of the statements though similiar. I am attempting to redirect the next 443 traffic to 62443...62446 as needed. Instead all traffic is showing as 2.16 at the web server. See below.

access-list outside_access_in permit tcp any interface outside eq https

static (dmz,outside) tcp interface https 192.168.2.16 https netmask 255.255.255.255 0 0

static (dmz,outside) tcp interface 62443 192.168.2.12 https netmask 255.255.255.255 0 0

static (dmz,outside) tcp interface 62444 192.168.2.13 https netmask 255.255.255.255 0 0

static (dmz,outside) tcp interface 62445 192.168.2.14 https netmask 255.255.255.255 0 0

static (dmz,outside) tcp interface 62446 192.168.2.15 https netmask 255.255.255.255 0 0

scoclayton · ‎03-31-2005

I'm confused...is the traffic arriving on the outside of the PIX with a destination address of the PIX outside interface and a destination port of 62443 or 63444 or etc...? You config indicates this but your description does not (at least to me).

Scott

brenteads · ‎04-01-2005

Traffic is comming in as 443 and redirected as 62xxx because of various different IP addresses can't use the same port over and over again. Traffic has to be sent to the web box as a different port each instance. Thus the web server has to be configured to recieve similiar redirects for 443 traffic as well. Port 80 simply gets redirected internally to 443 as a separate header so that works.

scoclayton · ‎04-01-2005

Still confused...

Let's try this a different way then. Here is your config:

static (dmz,outside) tcp interface https 192.168.2.16 https netmask 255.255.255.255 0 0

static (dmz,outside) tcp interface 62443 192.168.2.12 https netmask 255.255.255.255 0 0

static (dmz,outside) tcp interface 62444 192.168.2.13 https netmask 255.255.255.255 0 0

static (dmz,outside) tcp interface 62445 192.168.2.14 https netmask 255.255.255.255 0 0

static (dmz,outside) tcp interface 62446 192.168.2.15 https netmask 255.255.255.255 0 0

These commands tell the PIX that if it receives a packet destined for port 443 and the outside interface IP address, then it should re-direct the packet to 192.168.2.16 on port 443. If the PIX receives a packet destined for port 62443 and the outside interface IP address, then the PIX should re-direct the packet to 192.168.2.12 on port 443. If the PIX receives a packet destined for port 62444 and the outside interface IP address, then the PIX should re-direct the packet to 192.168.2.13 on port 443. Etc...

I am still not clear from your description, if the PIX is receiving packets on it's outside interface destined for port 443 or port 6244X. Your configuration will work as I indicated above.

Scott

brenteads · ‎04-01-2005

Traffic should appear to be comming in as 443 (SSL) via a https:\\ header. Because the destination is a multi-homed box with numerous web sites hosted. Adding IP addresses for each site with SSL is the only way to provision this.

Once inside the PIX the traffic needs to be mapped to 6244x (any open port seq. I just picked this as being unused), internally, feed to the web server with the same port address, then back out again. Clear as mud, I understand.

What is happening is that all traffic no matter how I map it is going to 192.186.2.16:443 irregardless of mapping or atleast as far as I can tell, thus far. In theory this should work. In practice I haven't been able to "pull up" the web pages from outside.

Any insights will be graciously welcomed.

scoclayton · ‎04-03-2005

This will not work, if I understand what you are trying to do. You are trying to have the PIX re-direct packets that have a destination address of the PIX interface and on port 443 to one of the 5 dmz servers. How would the PIX distinguish between packets meant for server1 and those meant for server5? Does this make sense? Your config is telling the PIX to listen for packets with a destination address of the outside interface and destination port of 62XXX.

Scott

brenteads · ‎04-04-2005

Scott;

I did open the ports comming after my last posting but to no avail. Does what your saying make sense? Yes, it does. Quite clearly but not before I tried to redirect SSL (port 443) this way.

After going through three packet sniffing sessions, one using DEBUG, one with a traditional sniffer and MS network analyzer. I can see that the base problem is how PIX uses broadcast. Nothing wrong with PIX in this regard. The way I am interpreting the data, PIX doesn't broadcast 443 like other protocols. Rather, staying with a more rigid interpretation of the SSL RFC.

How to solve the problem? Add an outside IP address for each SSL cert with 'A' records at the ISP/local DNS, a group access list and no port redirection for SSL traffic. That works fine if you have a bunch of unused IP addresses. Which I found I did have access to but it wasn't the solution that I was attempting.

Though the solution was on the right track and would work for anything but SSL, it was a huge learning experience.

Thanks again! If anyone would like to see the before and after for the solution. Let me know and I will post below. I doubt this will be the last time the problem will come up for someone.

Again, thanks all!