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

Discussion in 'Cisco' started by joshkeely, Jan 4, 2006.

  1. joshkeely

    joshkeely Guest

    Hi all,
    I am having a problem with my PIX 501. I have a computer behind that
    has several IP Addresses bound to the adapter, i.e.:
    10.10.0.1
    10.10.0.2
    10.10.0.3

    Because I have 3 public IP Addresses that needs to route to the same
    server, meaning when someone pings 209.14.222.101 I need it to go to
    SERVERA, but I also need 209.14.222.102 to go to SERVERA, and the only
    way I saw to do this in the PIX was to add several route commands:


    static (inside,outside) 209.14.222.101 10.10.0.1 netmask
    255.255.255.255 0 0
    static (outside,inside) 10.10.0.1 209.14.222.101 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 (outside,inside) 10.10.0.2 209.14.222.102 netmask
    255.255.255.255 0 0

    When I set it up this way, I get random ping results, dropped packets,
    certain IP's will not respond, etc...I think it is confused because of
    the multiple IP addresses bound to the same adapter on the machine
    SERVERA.

    Any way around this? some kind of ARP entry or something?

    Any help is MUCH appreciated!!!!!

    Josh
     
    joshkeely, Jan 4, 2006
    #1
    1. Advertisements

  2. joshkeely

    mcaissie Guest

    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
    255.255.255.255 0 0
    no static (outside,inside) 10.10.0.2 209.14.222.102 netmask
    255.255.255.255 0 0
    no static (outside,inside) 10.10.0.3 209.14.222.103 netmask
    255.255.255.255 0 0
    clear xlate

    and try again

    It should work , assuming you have proper accees-group/list
     
    mcaissie, Jan 4, 2006
    #2
    1. Advertisements

  3. 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.)
     
    Walter Roberson, Jan 6, 2006
    #3
  4. joshkeely

    joshkeely Guest

    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


     
    joshkeely, Jan 9, 2006
    #4
  5. :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.
     
    Walter Roberson, Jan 10, 2006
    #5
  6. 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.
     
    Vincent C Jones, Jan 10, 2006
    #6
  7. joshkeely

    joshkeely Guest

    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.
     
    joshkeely, Jan 12, 2006
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.