Problem with multiple IP's assigned to one server behind PIX 501...

If you want to mask the IP 10.10.0.1 with 209.14.222.101, you only need one static entry not two. You don't want to mask 209.14.222.101 with 10.10.0.1 so the static (outside,inside) are useless.

So for your 3 addresses the following lines should be sufficient; static (inside,outside) 209.14.222.101 10.10.0.1 netmask 255.255.255.255 0 0 static (inside,outside) 209.14.222.102 10.10.0.2 netmask 255.255.255.255 0 0 static (inside,outside) 209.14.222.103 10.10.0.3 netmask 255.255.255.255 0 0

Just do a ; no static (outside,inside) 10.10.0.1 209.14.222.101 netmask

and try again

It should work , assuming you have proper accees-group/list

You can't do that with a PIX: when SERVERA goes to reply to the ping packets, the PIX would not have any way of knowing which IP address to put on the outgoing packet.

Think of it from the point of view of what the source and destination IPs are on the ping packets that get to SERVERA: the source could be any host because any host might have chosen to ping any of the three IP addresses; the destination on the packets can only be SERVERA or else the packets will not get to SERVERA. Now imagine the reply: the source for the reply will be SERVERA in all three cases, and the destination could be anywhere. How would the PIX know which IP address to put as the source of the outgoing packet?

You might be thinking, "But the packet came in and the IP address used would have been recorded then, so it could just look up the destination IP address and use the IP that that IP addressed to". The problem with that is that the same source IP might be pinging more than one of your destinations.

You might be thinking that it could look at the icmp ping "id", but the "id" is not required to be unique: a host that is pinging all three of your public IPs might be using the same icmp ping "id" on all of the pings.

There are cases where it is possible to have different public IPs map to the same internal IP, but those cases are:

- TCP or UDP and the destination ports differ for cases (e.g., pubic IP#1 port tcp 80 might map to SERVERA destination port tcp 801, public IP#2 port tcp 80 might map to SERVERA destination port tcp 802); the destination port that is mapped to does not need to be the same as the destination port that was addressed for this case

- different source IPs and/or different source ports can map differently to the same destination IP + port combination, provided a "policy static" is used (an access list is able to fully disambiguate all the cases); the destination port that is mapped to will be the same as the destination port that was addressed for this case [actually you can combine this mechanism and the one above]

- similar to the above, but different source IP + protocol combinations can map to the same destination IP, provided a "policy static" is used (an access list that disambiguates all the cases); the protocol would stay the same in this case

- similar to the above, but different source IP + icmp major types, again using "policy static"; the icmp type would stay the same in this case

For example, you could have protocol 47 (GRE) map to a different destination than for protocol 50 (ESP), or you could have icmp echo map to a different destination than icmp unreachable .

However, the case you specified uses the same source ("any") and the same icmp major type (echo) in each case, so the PIX cannot handle it.

The PIX can, though, map the same protocol or icmp type for different public IPs to different internal addresses:

static (inside,outside) PUBLICIP1 INTERNALIP1 static (inside,outside) PUBLICIP2 INTERNALIP2

The PIX doesn't care if the same -machine- answers to three different internal IP addresses, it just cares that the mapping combination is unique at the IP, TCP or UDP level. On the other hand, for this to work properly, if the same machine answers to different IP addresses, it is the responsibility of the machine to ensure that the reply packets have the correct source IP address on them. If a machine receives packets addressed to 10.0.0.2 and 10.0.0.3 but the replies it generates are always from 10.0.0.2 then the PIX will drop the unexpected packets (if it can figure out they are unexpected... which it can pretty much always do for TCP, and can do for -some- kinds of UDP, if the UDP protocol is one that "fixup" or "inspect" has been configured for.)

Wow, thanks Walter...I have to say I am still a bit confused however....you wouldn't happen to live in the Atlanta area, would you? I am in desperate need of someone who knows what they are doing to configure my network.....

It sounds like you are saying there is no way to map multiple IP address on the outside to one IP address on the inside on ONE machine, or to multiple address on ONE machine...

Did I read you correctly? You are saying I would have to change TCP ports, say put web on port 81 instead of 80 and have it map to that?

Thanks in advance!! Josh

Walter Robers> > > I am having a problem with my PIX 501.

In article , wrote: :Wow, thanks Walter...I have to say I am still a bit confused :however....you wouldn't happen to live in the Atlanta area, would you? :I am in desperate need of someone who knows what they are doing to :configure my network.....

Sorry, 1575 miles away...

If you want to be able to map multiple things to the same destination machine, then you need to be able to statically differentiate the cases via an access list. The difference could be on IP protocol #, on ICMP vs TCP vs UDP, on source IP, on source port, destination port, or on icmp type -- if you can describe the differenc through an ACL then you can have different mappings for it.

In my previous message, I showed that given the criteria you set out earlier, you can NOT differentiate the cases using an ACL.

But to emphasize, all this is at the *IP* level. If you have public IP #1 map to private IP A, and public IP #2 map to private IP B, then it does not matter to the PIX whether A and B happen to be served by the same actual machine -- as long as the machine does its part and somehow -it- figures out which IP address to use when it is generating the replies.

Careful that you don't sink into the trap of being penny wise and dollar foolish. There is no difference between 1 mile and 1575 miles as far as telephone and email support for the kinds of questions you seem to be asking. You only need to "be there" if there is NO competency on site, in which case you wouldn't be on Usenet either.

FWIW, I would worry far more about finding someone competent than I would about finding someone close. Although if you can do both, so much the better, because there is nothing to beat the learning that comes from a face to face encounter.

Well, Good point Vincent...Walter, if you are interested in making some xtra cash on the side, let me know, we could do webex or something, and you could get in my environment and see things.

Thanks guys.

Josh V> > >> >:Wow, thanks Walter...I have to say I am still a bit confused