PIX 535 firewall translation

You are missing a step in here, the old "public" IP address for the print server that the mainframe outside was addressing.

e.g., there must have been something like

static (inside,outside) 64.65.66.67 192.168.1.25

with the mainframe sending its print job to 64.65.66.67 and reaching

192.168.1.25 in so doing.

If that was the only public traffic that was permitted to 64.65.66.67 then just change that line to the equivilent of

static (inside,outside) 64.65.66.67 172.0.5.89

You would only need a selective change if 64.65.66.67 is to continue to be the public IP of the renumbered host 172.0.5.89 only when talking to 10.0.0.1 and there is a different public IP now for 172.0.5.89 that should be used for other traffic. If you are in that situation, you need to replace the single static with a pair of static's that have access-list qualifiers:

access-list redirectMF permit tcp host 172.0.5.89 eq lpr host 10.0.0.1

access-list noredirectMF deny tcp host 172.0.5.89 eq lpr host 10.0.0.1 access-list noredirectMF permit ip host 172.0.5.89 any

static (inside,outside) 64.65.66.67 access-list redirectMF static (inside,outside) 128.130.132.134 access-list noredirectMF

This has to be done as two entries both with access-lists, "Because you cannot use the same local address in static NAT or static PAT commands, the order of static commands does not matter. Similarly, for static policy NAT, you cannot use the same local/destination address and port across multiple statements."

There is no print server. The main frame prints directly to a high speed IP printer. I.E. main frame -----> printer the current PIX acl is a static mappping of main frame to printer IP.

I need something that would still allow it to come from the main frame to the same printer IP but then redirect it to the new IP at the firewall

I.E. main frame ------> old printer IP ---->redirect-----> new printer IP

Is this possible? thanks for the help and your time.

Then the printer is acting as the print server. It doesn't matter; everything I wrote applies whether there is a seperate print server or you are going direct to the printer.

Then either you have misdescribed your situation or your printing did not work before.

The mainframe has an IP address. You said that was 10.0.0.1 . The mainframe has to send to *some* IP address in order to get its documents printed. You did not indicate before which IP address that was. In my response, I used 64.65.66.67 as that IP address that the mainframe is sending the document to. The old PIX static mapping would have had to have been a mapping between the address that the mainframe sends its print data *to* and the internal IP address of the printer.

Yes, and I already showed you how to do it.

When you have a static command such as

static (inside,outside) 64.65.66.67 192.168.17.49 netmask 255.255.255.255

then when inside host 192.168.17.49 communicates with the outside world, all the outgoing packets (from inside the PIX to outside) are rewritten so that the source IP becomes 64.65.66.67, and -that- IP is what the outside device (e.g., the mainframe) sees as the packet source, and that IP is the IP address that the outside device has to send packets to in order to get them back to the printer. When the PIX receives packets from the outside with the destination address

64.65.66.67 it will rewrite the destination to be 192.168.17.49 . Thus if the printer should continue to have the same public IP address (64.65.66.67 in this example) for talking to everything, then all you need to do is change the one static,

static (inside,outside) 64.65.66.67 172.16.5.179 netmask 255.255.255.255

But you might have a situation in which everything outside -other- than the mainframe should talk to the printer with a new public IP address such as 128.130.132.134 and only the mainframe should still use the old public IP 64.65.66.67 . If that is the case then you have to use two static commands and two access-lists in order to split the traffic so that the mainframe sees the old public address and everything else sees the new public address.

To repeat myself for emphasis: if -all- of the outside devices that talk to the printer should continue to use the old public address for the printer, then just change the internal IP address on the 'static' command.

Possibly you have configured such the the public IP address is the same as the internal IP address,

static (inside,outside) 192.168.17.49 192.168.17.49 netmask 255.255.255.255

If so, and if -all- the outside devices that talk to the printer should continue to refer to it using the old IP address, then just change the static:

static (inside,outside) 192.168.17.49 172.16.5.179 netmask 255.255.255.255

and packets will get rewritten to do the redirection that you want.

Ok, I am a knuckle head and I am just not getting it. Let me lay it out.

The reason I want the main frame to continue to print to the same IP is because there are a series of several firewalls and holes to allow the traffic(print jobs) through between it and me. It is a pain to get all of those changed. So my thought was that though my internal IP schema has changed, could I see the print job coming from the main frame to the old printer IP hitting the (outside) interface of the PIX going through a static acl and then changing the print job to the new internal IP. The actual IPs for the firewall has not changed just all the internal network ones.

Old config

mainframe(10.0.0.1)----->outside int pix----->inside int pix ------>

old printer IP (192.168.1.25)

new config

mainframe(10.0.0.1)----->outside int pix------>receive old printer IP print job (192.168.1.25)----->change print job to new IP (172.0.5.89)------->inside int pix ------>new printer IP (172.0.5.89)

I know I am trying your patience, but if you could give it one more try and walk this rock through it I would greatly appreciate it. thanks!

How about using the alias command?

alias 192.168.1.25 172.0.5.89 255.255.255.255 static (outside, inside) 10.0.0.1 192.168.1.25 access-list permit PRINTER host 10.0.0.1 host 192.168.1.25 eq lpr

Would this work?

No.

You do not need any special configuration to get the PIX to receive packets on behalf of the old printer IP and to rewrite the packets so they are addressed to the new IP. All of that work is done just by

static (inside,outside) PRINTERPUBLICIP 172.0.5.89

where PRINTERPUBLICIP is the IP address of the printer

*as known to the mainframe*.

You appear to be stuck on the distinction between public IP addresses and internal IP addresses. I suggest you consult the Cisco PIX Firewall and VPN Configuration Guide appropriate for the software release you have on the PIX. For example

I have no NAT. All the IP's in my network about 2500 are routable, advertised through DNS and can be reached externally with a static. The problem is I have a printer that has changed its IP and I don't want to have all the intervening firewalls as well as the main frame change the IP they send traffic to or traffic through in order to continue receving print jobs. If I just use the static you reference above how would the print jobs going to the old public printer IP get routed/allowed through the firewall to the new public printer IP? There has to be some sort of pointer, alias or redirection to allow this to happen. Or am I totally off my rocker? Signed

A static command *is* a redirection.

If you have

static (inside,outside) 172.0.5.89 172.0.5.89 netmask 255.255.255.255

then that redirects traffic reaching the outside interface that is addressed to 172.0.5.89 so that the traffic instead gets sent to the inside interface addressed to 172.0.5.89 . In this case, the destination IP address would stay the same and the redirection would be a matter of changing interfaces.

If you have

static (inside,outside) 192.168.1.25 172.0.5.89 netmask 255.255.255.255

then that redirects traffic reaching the outside interface that is addressed to 192.168.1.25 so that the traffic instead gets sent to the inside interface addressed to 172.0.5.89 . In this case, the destination IP address in the packets will be rewritten so that what reaches 172.0.5.89 will look as if the packet had always been addressed to 172.0.5.89

static commands are one form of Network Address Translation, even when the addresses and ports stay the same. (I won't explain why here because it would just confuse the issue.)

Ok I'm a dummy. I get it now, you just had to draw it with the big crayolas. You have a huge amount of patience. Thanks!