PIX with no nat

Discussion in 'Cisco' started by Gary, Feb 5, 2005.

  1. Gary

    Gary Guest

    Can the pix handle the same network on both inside and outside interfaces. I
    simply want the pix to protect some machines in the 10.15.0.0/24 from other
    machines in the 10.15.0.0/24 range

    i.e Like a filter between hosts

    Gary
    Gary, Feb 5, 2005
    #1
    1. Advertising

  2. In article <nRVMd.19820$Vg3.8086@lakeread05>,
    Gary <> wrote:

    :Can the pix handle the same network on both inside and outside interfaces.

    No, definitely not.


    :I simply want the pix to protect some machines in the 10.15.0.0/24 from other
    :machines in the 10.15.0.0/24 range
    :i.e Like a filter between hosts


    {10.15.0/24 cloud 1} ---- 10.15.0.1 [PIX #1] 10.16.0.1
    ______________________10.1?.0.x____________________|
    |
    --- 10.16.0.2 [PIX #2] 10.15.0.1 ---- {10.15.0/24 cloud 2}


    PIX #1:

    ip address inside 10.15.0.1 255.255.255.0
    ip address outside 10.16.0.1 255.255.255.252
    static (inside, outside) 10.17.0.0 10.15.0.0 netmask 255.255.255.0 dns
    route outside 10.18.0.0 255.255.255.0 10.16.0.2

    access-list cloud1to2 deny ip host 10.15.0.39 host 10.18.0.82
    access-list cloud1to2 permit ip 10.15.0.0 255.255.255.0 10.18.0.0 255.255.255.0

    access-list cloud2to1 deny ip host 10.18.0.82 host 10.17.0.81
    access-list cloud2to1 permit ip 10.18.0.0 255.255.255.0 10.17.0.0 255.255.255.0

    access-group cloud1to2 in interface inside
    access-group cloud2to1 in interface outside

    PIX #2:

    ip address inside 10.15.0.1 255.255.255.0
    ip address outside 10.16.0.2 255.255.255.252
    static (inside, outside) 10.18.0.0 10.15.0.0 netmask 255.255.255.0 dns
    route outside 10.17.0.0 255.255.255.0 10.16.0.1

    access-list cloud2to1 deny ip host 10.15.0.82 host 10.17.0.81
    access-list cloud2to1 permit ip 10.15.0.0 255.255.255.0 10.17.0.0 255.255.255.0

    access-list cloud1to2 deny ip host 10.17.0.39 host 10.18.0.82
    access-list cloud1to2 permit ip 10.17.0.0 255.255.255.0 10.18.0.0 255.255.255.0

    access-group cloud2to1 in interface inside
    access-group cloud1to2 in interface outside


    In this setup, devices in cloud 1 have to address 10.18.0.x to talk to
    remote device 10.15.0.x, and devices in cloud 2 have to address
    10.17.0.x to talk to remote device 10.15.0.x in cloud 1. If they are
    addressing by direct IP address, they will just have to know that. If they
    are using hostnames or urls with hostnames, the translation will happen
    provided that you make the appropriate adjustments to include a DNS
    server or two.
    --
    WW{Backus,Church,Dijkstra,Knuth,Hollerith,Turing,vonNeumann}D ?
    Walter Roberson, Feb 5, 2005
    #2
    1. Advertising

  3. Gary

    Gary Guest

    "Walter Roberson" <-cnrc.gc.ca> wrote in message
    news:cu1cr3$ljf$...
    > In article <nRVMd.19820$Vg3.8086@lakeread05>,
    > Gary <> wrote:
    >
    > :Can the pix handle the same network on both inside and outside

    interfaces.
    >
    > No, definitely not.
    >
    >
    > :I simply want the pix to protect some machines in the 10.15.0.0/24 from

    other
    > :machines in the 10.15.0.0/24 range
    > :i.e Like a filter between hosts
    >
    >
    > {10.15.0/24 cloud 1} ---- 10.15.0.1 [PIX #1] 10.16.0.1
    > ______________________10.1?.0.x____________________|
    > |
    > --- 10.16.0.2 [PIX #2] 10.15.0.1 ---- {10.15.0/24 cloud 2}
    >
    >
    > PIX #1:
    >
    > ip address inside 10.15.0.1 255.255.255.0
    > ip address outside 10.16.0.1 255.255.255.252
    > static (inside, outside) 10.17.0.0 10.15.0.0 netmask 255.255.255.0 dns
    > route outside 10.18.0.0 255.255.255.0 10.16.0.2
    >
    > access-list cloud1to2 deny ip host 10.15.0.39 host 10.18.0.82
    > access-list cloud1to2 permit ip 10.15.0.0 255.255.255.0 10.18.0.0

    255.255.255.0
    >
    > access-list cloud2to1 deny ip host 10.18.0.82 host 10.17.0.81
    > access-list cloud2to1 permit ip 10.18.0.0 255.255.255.0 10.17.0.0

    255.255.255.0
    >
    > access-group cloud1to2 in interface inside
    > access-group cloud2to1 in interface outside
    >
    > PIX #2:
    >
    > ip address inside 10.15.0.1 255.255.255.0
    > ip address outside 10.16.0.2 255.255.255.252
    > static (inside, outside) 10.18.0.0 10.15.0.0 netmask 255.255.255.0 dns
    > route outside 10.17.0.0 255.255.255.0 10.16.0.1
    >
    > access-list cloud2to1 deny ip host 10.15.0.82 host 10.17.0.81
    > access-list cloud2to1 permit ip 10.15.0.0 255.255.255.0 10.17.0.0

    255.255.255.0
    >
    > access-list cloud1to2 deny ip host 10.17.0.39 host 10.18.0.82
    > access-list cloud1to2 permit ip 10.17.0.0 255.255.255.0 10.18.0.0

    255.255.255.0
    >
    > access-group cloud2to1 in interface inside
    > access-group cloud1to2 in interface outside
    >
    >
    > In this setup, devices in cloud 1 have to address 10.18.0.x to talk to
    > remote device 10.15.0.x, and devices in cloud 2 have to address
    > 10.17.0.x to talk to remote device 10.15.0.x in cloud 1. If they are
    > addressing by direct IP address, they will just have to know that. If they
    > are using hostnames or urls with hostnames, the translation will happen
    > provided that you make the appropriate adjustments to include a DNS
    > server or two.
    > --
    > WW{Backus,Church,Dijkstra,Knuth,Hollerith,Turing,vonNeumann}D ?


    Are you saying I will need 2 PIX's to do this.

    I cannot see what you are detailing here - Looks like 2 PIX's reflecting the
    address space to basically route between 2 - 10.15.0.0 interfaces.

    DNS is not relevant at all as they will always be referenced by IP.

    I guess is I need 2 PIX's to do tyhis it begs the questions - Is a PIX the
    right device?

    BTW What does the WW{...}D mean in your signature. I see the great names
    etc - Is the WWD some programming language

    Gary

    Gary
    Gary, Feb 5, 2005
    #3
  4. In article <maXMd.19831$Vg3.4942@lakeread05>,
    Gary <> wrote:

    > Are you saying I will need 2 PIX's to do this.
    >
    > I cannot see what you are detailing here - Looks like 2 PIX's reflecting
    > the address space to basically route between 2 - 10.15.0.0 interfaces.
    >
    > DNS is not relevant at all as they will always be referenced by IP.
    >
    > I guess is I need 2 PIX's to do this it begs the questions - Is a PIX
    > the right device?


    As an alternative for this specific requirement, the Transparent Cisco IOS
    Firewall might be a better fit, as introduced in 12.3(7)T, unless you
    require specific functionality from PIX, which is not available in CBAC
    (Cisco IOS Firewall).

    Cheers,

    Matt

    --
    Matthew Melbourne
    Matthew Melbourne, Feb 5, 2005
    #4
  5. In article <maXMd.19831$Vg3.4942@lakeread05>,
    Gary <> wrote:
    :Are you saying I will need 2 PIX's to do this.

    I'm not sure at the moment.

    Suppose you have just 1 PIX. Recall what I said about it not
    being possible for the two interfaces to be in the same subnet.
    So let the inside of the PIX be in 10.15.0/24, and let the outside
    be in some other range (e.g., 10.16.0.1/29). One can then use
    static (inside, outside) 10.15.0.23 10.15.0.23 netmask 255.255.255.255
    and so on for each invidual 10.15.0/24 IP that is on the inside of
    the PIX; this will allow the outside of the PIX to proxy arp for those
    IPs, so if the PIX is put onto the same segment as the other 10.15.0/24
    then the PIX will transparently grab traffic for those inside IPs
    even though the PIX outside interface is in a different subnet.

    Now the question becomes how to reverse the process, and allow the
    10.15.0/24 on the "outside" of the PIX to be visible inside.
    What can be tried is, e..g.,

    static (outside,inside) 10.15.0.88 10.15.0.88 netmask 255.255.255.255 outside
    route outside 10.15.0.88 255.255.255.255 10.16.0.1

    I have confirmed that if that is set up that the PIX will build
    translations as if it is going to send the packet out, but I have not
    yet been able to confirm that the PIX actually sends the packets out.
    Using 'capture' against the inside interface, I can see that the
    packets are accepted by the inside interface, but capture against the
    outside interface does not appear to show the packet leaving.
    My equipment here is not set up to be able to test the scenario
    by placing devices on both sides.


    :I cannot see what you are detailing here - Looks like 2 PIX's reflecting the
    :address space to basically route between 2 - 10.15.0.0 interfaces.

    Sort of. It's the ole switcheroo: if you need to talk about IPs that
    you can't talk about, then you talk about other IPs instead and let
    the PIX translate them into the real IPs.


    :I guess is I need 2 PIX's to do tyhis it begs the questions - Is a PIX the
    :right device?

    Probably not with 6.x. I cannot tell from the feature summaries for 7.0
    whether it will be possible in 7.0.
    --
    Live it up, rip it up, why so lazy?
    Give it out, dish it out, let's go crazy, yeah!
    -- Supertramp (The USENET Song)
    Walter Roberson, Feb 5, 2005
    #5
  6. Gary

    Gary Guest

    "Walter Roberson" <-cnrc.gc.ca> wrote in message
    news:cu3097$oao$...
    > In article <maXMd.19831$Vg3.4942@lakeread05>,
    > Gary <> wrote:
    > :Are you saying I will need 2 PIX's to do this.
    >
    > I'm not sure at the moment.
    >
    > Suppose you have just 1 PIX. Recall what I said about it not
    > being possible for the two interfaces to be in the same subnet.
    > So let the inside of the PIX be in 10.15.0/24, and let the outside
    > be in some other range (e.g., 10.16.0.1/29). One can then use
    > static (inside, outside) 10.15.0.23 10.15.0.23 netmask 255.255.255.255
    > and so on for each invidual 10.15.0/24 IP that is on the inside of
    > the PIX; this will allow the outside of the PIX to proxy arp for those
    > IPs, so if the PIX is put onto the same segment as the other 10.15.0/24
    > then the PIX will transparently grab traffic for those inside IPs
    > even though the PIX outside interface is in a different subnet.
    >
    > Now the question becomes how to reverse the process, and allow the
    > 10.15.0/24 on the "outside" of the PIX to be visible inside.
    > What can be tried is, e..g.,
    >
    > static (outside,inside) 10.15.0.88 10.15.0.88 netmask 255.255.255.255

    outside
    > route outside 10.15.0.88 255.255.255.255 10.16.0.1
    >
    > I have confirmed that if that is set up that the PIX will build
    > translations as if it is going to send the packet out, but I have not
    > yet been able to confirm that the PIX actually sends the packets out.
    > Using 'capture' against the inside interface, I can see that the
    > packets are accepted by the inside interface, but capture against the
    > outside interface does not appear to show the packet leaving.
    > My equipment here is not set up to be able to test the scenario
    > by placing devices on both sides.
    >
    >
    > :I cannot see what you are detailing here - Looks like 2 PIX's reflecting

    the
    > :address space to basically route between 2 - 10.15.0.0 interfaces.
    >
    > Sort of. It's the ole switcheroo: if you need to talk about IPs that
    > you can't talk about, then you talk about other IPs instead and let
    > the PIX translate them into the real IPs.
    >
    >
    > :I guess is I need 2 PIX's to do tyhis it begs the questions - Is a PIX

    the
    > :right device?
    >
    > Probably not with 6.x. I cannot tell from the feature summaries for 7.0
    > whether it will be possible in 7.0.
    > --
    > Live it up, rip it up, why so lazy?
    > Give it out, dish it out, let's go crazy, yeah!
    > -- Supertramp (The USENET Song)


    Do not mind using 2 PIX's but need to know if it will work before I buy
    another.

    Is your solution a real one that will work or best guess. It looks good to
    me.

    Gary
    Gary, Feb 5, 2005
    #6
  7. In article <BC8Nd.20417$Vg3.11209@lakeread05>,
    Gary <> wrote:
    :Do not mind using 2 PIX's but need to know if it will work before I buy
    :another.

    :Is your solution a real one that will work or best guess. It looks good to
    :me.

    I have used a similar solution to deal with overlapping address spaces
    for a VPN tunnel:

    172.16.N/24 -- remote vpn concentrator <==VPN==> our PIX 172.16/16

    On our pix,

    name 192.P.Q.R ALocalServer
    name 172.16.N.80 RemoteHostIP
    name 172.17.N.80 LocalMappedIP

    access-list vpn2remote permit ip host ALocalServer host RemoteHostIP

    static (outside,inside) RemoteHostIP LocalMappedIP netmak 255.255.255.255 0 0

    crypto map vpn-map 1000 match address vpn2remote

    When our local server wants to talk to RemoteHostIP (which overlaps one
    of our internal networks), we address the packets to LocalMappedIP
    instead. The PIX sees the reverse nat [notice the interface order
    change], it rewrites the destination IP that we used internally
    into the real destination IP and then notices that that the result
    matches the vpn tunnel ACL vpn2remote so it pushes the traffic through
    the tunnel. It so happens that all of the hosts that RemoteHostIP
    needs to talk to on our side are in public IP space, not in the overlapped
    IP space [well, it's not really an accident -- we use public IP space
    for any host that has to be remotely reachable] so in our situation
    there is no issue about having to get the remoted end to do the same
    kind of mapping trick. The trick can in theory be done with only
    one side doing the mapping, by using both a
    static (outside,inside) and a static (inside,outside)
    but I haven't tested that.


    :Do not mind using 2 PIX's but need to know if it will work before I buy
    :another.

    That's what lab tests are for. You do enough PIX work that you should have
    an extra PIX 501 or two on hand specifically to be able to test out
    scenarios and test out PIX software upgrades and to syntax-check
    notable configuration rewrites before putting the revised config
    onto a production system.

    Keep in mind that entry PIX 501's have that 10 user license, so
    you probably would want to go for PIX 506E if you have more than ~20
    hosts on each side.

    Other thing to keep in mind is that having a PIX or two in the
    middle is *not* the same as having a "transparent filter": there are
    differences in UDP handling and especially differences in TCP handling
    when it comes to long-running connections. And if you have netbios
    in there, it really becomes a pain as the PIX doesn't rewrite
    addresses that are flowing through TCP 139 [or so the TAC told me
    two days ago.]

    You also have a problem if the devices on the two "clouds" are on
    the same segment without any choke-point inbetween: in such a case,
    anyone could get around the filter by simply directly addressing the
    remote system instead of addressing the mapped IP corresponding
    to the remote system.

    If you do have a choke point, then considering that everyone on
    one side is going to have to use other IPs to address everyone on
    the other side, it probably makes more sense to simply put in one
    PIX total and re-number the hosts on one side so they are no longer
    in 10.15.0/24.
    --
    Are we *there* yet??
    Walter Roberson, Feb 5, 2005
    #7
  8. Gary

    Lars Molstad Guest

    PIX 7.0 software will do this, as it can be a transparent firewall, but
    software is to be released later this year....

    L@rs
    "Gary" <> wrote in message
    news:nRVMd.19820$Vg3.8086@lakeread05...
    > Can the pix handle the same network on both inside and outside interfaces.
    > I
    > simply want the pix to protect some machines in the 10.15.0.0/24 from
    > other
    > machines in the 10.15.0.0/24 range
    >
    > i.e Like a filter between hosts
    >
    > Gary
    >
    >
    Lars Molstad, Feb 7, 2005
    #8
  9. Gary

    Gary Guest

    > :Can the pix handle the same network on both inside and outside
    interfaces.
    >
    > No, definitely not.
    >
    >
    > :I simply want the pix to protect some machines in the 10.15.0.0/24 from

    other
    > :machines in the 10.15.0.0/24 range
    > :i.e Like a filter between hosts
    >
    >
    > {10.15.0/24 cloud 1} ---- 10.15.0.1 [PIX #1] 10.16.0.1
    > ______________________10.1?.0.x____________________|
    > |
    > --- 10.16.0.2 [PIX #2] 10.15.0.1 ---- {10.15.0/24 cloud 2}
    >
    >
    > PIX #1:
    >
    > ip address inside 10.15.0.1 255.255.255.0
    > ip address outside 10.16.0.1 255.255.255.252
    > static (inside, outside) 10.17.0.0 10.15.0.0 netmask 255.255.255.0 dns
    > route outside 10.18.0.0 255.255.255.0 10.16.0.2
    >
    > access-list cloud1to2 deny ip host 10.15.0.39 host 10.18.0.82
    > access-list cloud1to2 permit ip 10.15.0.0 255.255.255.0 10.18.0.0

    255.255.255.0
    >
    > access-list cloud2to1 deny ip host 10.18.0.82 host 10.17.0.81
    > access-list cloud2to1 permit ip 10.18.0.0 255.255.255.0 10.17.0.0

    255.255.255.0
    >
    > access-group cloud1to2 in interface inside
    > access-group cloud2to1 in interface outside
    >
    > PIX #2:
    >
    > ip address inside 10.15.0.1 255.255.255.0
    > ip address outside 10.16.0.2 255.255.255.252
    > static (inside, outside) 10.18.0.0 10.15.0.0 netmask 255.255.255.0 dns
    > route outside 10.17.0.0 255.255.255.0 10.16.0.1
    >
    > access-list cloud2to1 deny ip host 10.15.0.82 host 10.17.0.81
    > access-list cloud2to1 permit ip 10.15.0.0 255.255.255.0 10.17.0.0

    255.255.255.0
    >
    > access-list cloud1to2 deny ip host 10.17.0.39 host 10.18.0.82
    > access-list cloud1to2 permit ip 10.17.0.0 255.255.255.0 10.18.0.0

    255.255.255.0
    >
    > access-group cloud2to1 in interface inside
    > access-group cloud1to2 in interface outside
    >
    >
    > In this setup, devices in cloud 1 have to address 10.18.0.x to talk to
    > remote device 10.15.0.x, and devices in cloud 2 have to address
    > 10.17.0.x to talk to remote device 10.15.0.x in cloud 1. If they are
    > addressing by direct IP address, they will just have to know that. If they
    > are using hostnames or urls with hostnames, the translation will happen
    > provided that you make the appropriate adjustments to include a DNS
    > server or two.
    > --
    > WW{Backus,Church,Dijkstra,Knuth,Hollerith,Turing,vonNeumann}D ?



    OK> One more detail. The machines either side of the PIX's cannot change
    what IP's they talk to. They can only talk to 10.15.0.0/24 address's. Can we
    use ARP on the PIX's to somehow allow this?

    Gary
    Gary, Feb 15, 2005
    #9
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Michael Gorsuch

    Pix-to-Pix VPN - BOTH BOXES BEHIND NAT!!!

    Michael Gorsuch, Oct 23, 2003, in forum: Cisco
    Replies:
    1
    Views:
    1,630
    Walter Roberson
    Oct 24, 2003
  2. Oleg Tipisov

    PIX Policy NAT: order of NAT commands

    Oleg Tipisov, Aug 12, 2004, in forum: Cisco
    Replies:
    4
    Views:
    8,709
    Walter Roberson
    Aug 13, 2004
  3. Jose Ros

    Pix to Pix tunnel through NAT

    Jose Ros, Oct 19, 2004, in forum: Cisco
    Replies:
    6
    Views:
    1,981
    an admin too
    Oct 21, 2004
  4. Jose
    Replies:
    3
    Views:
    1,912
  5. Matthew Melbourne
    Replies:
    2
    Views:
    7,293
    Matthew Melbourne
    Feb 12, 2005
Loading...

Share This Page