Rare scenario with VPN and NAT

Discussion in 'Cisco' started by ae, Oct 21, 2004.

  1. ae

    ae Guest

    Hi all

    I can't find this information on Cisco.com. Here is the scenario. Hope
    someone can shed some light.

    Companies A & B want to establish a VPN tunnel (using Routers A & B).

    Router A has the IP address of 100.1.1.1 (external). Its internal network
    has a host (Host A) with a private address of 192.168.1.2.

    Router B has the IP address of 200.1.1.1 (external). Its internal network
    also has a host (Host B) with a private address of 192.168.1.2 (same address
    as Host A).

    Obviously, Companies A & B have identical IP address space. Good thing is
    that only Host A can initiate requests to Host B (application server). Host
    B are not allowed to initiate request to Host A.

    The requirements are these:
    1. Traffic between Host A & B must be in VPN tunnel.
    2. Host A can use Router A's overloaded external address. This way Host B
    sees Host A as having an address of 100.1.1.1 (Router A's address).

    Do Cisco routers support this kind of configuration?

    Thanks.

    Al
     
    ae, Oct 21, 2004
    #1
    1. Advertising

  2. ae

    PES Guest

    I don't think that will be a problem if the private ranges weren't
    overlapping. On packets from inside to outside, nat happens before crypto.
    Therefore, you would simply specify the overloaded address as source in the
    crypto acl and the private range is the destination.

    There is, however, more than one problem. First of all, before nat host a
    is sending from 192.168.1.2 to 192.168.1.2, the packet will never leave the
    pc and certainly not be directed to the default gateway. If it were to make
    it to the router, the router would see 192.168.1.x as a directed connected
    and therefore route back out the same interface thus missing the crypto map.

    What you could do is overload on the external interface on router a and do a
    static nat on router b to a different subnet. Fore example on router b
    statically nat 192.168.1.2 to 192.168.2.2. If it is already natted to a
    public you could use that. If you build your crypto acl to reflect the
    packets after the nat, all should be fine. The only thing I would caution
    is to watch for a situation where nat would only occur in one direction.
    There are frequently posts about this.

    "ae" <> wrote in message
    news:B7Vdd.8590$...
    > Hi all
    >
    > I can't find this information on Cisco.com. Here is the scenario. Hope
    > someone can shed some light.
    >
    > Companies A & B want to establish a VPN tunnel (using Routers A & B).
    >
    > Router A has the IP address of 100.1.1.1 (external). Its internal network
    > has a host (Host A) with a private address of 192.168.1.2.
    >
    > Router B has the IP address of 200.1.1.1 (external). Its internal network
    > also has a host (Host B) with a private address of 192.168.1.2 (same
    > address
    > as Host A).
    >
    > Obviously, Companies A & B have identical IP address space. Good thing is
    > that only Host A can initiate requests to Host B (application server).
    > Host
    > B are not allowed to initiate request to Host A.
    >
    > The requirements are these:
    > 1. Traffic between Host A & B must be in VPN tunnel.
    > 2. Host A can use Router A's overloaded external address. This way Host B
    > sees Host A as having an address of 100.1.1.1 (Router A's address).
    >
    > Do Cisco routers support this kind of configuration?
    >
    > Thanks.
    >
    > Al
    >
    >
     
    PES, Oct 21, 2004
    #2
    1. Advertising

  3. ae

    Scooby Guest

    "PES" <NO*SPAMpestewartREMOVE**SUCKS> wrote in message
    news:41783052$...
    > I don't think that will be a problem if the private ranges weren't
    > overlapping. On packets from inside to outside, nat happens before

    crypto.
    > Therefore, you would simply specify the overloaded address as source in

    the
    > crypto acl and the private range is the destination.
    >
    > There is, however, more than one problem. First of all, before nat host a
    > is sending from 192.168.1.2 to 192.168.1.2, the packet will never leave

    the
    > pc and certainly not be directed to the default gateway. If it were to

    make
    > it to the router, the router would see 192.168.1.x as a directed connected
    > and therefore route back out the same interface thus missing the crypto

    map.
    >
    > What you could do is overload on the external interface on router a and do

    a
    > static nat on router b to a different subnet. Fore example on router b
    > statically nat 192.168.1.2 to 192.168.2.2. If it is already natted to a
    > public you could use that. If you build your crypto acl to reflect the
    > packets after the nat, all should be fine. The only thing I would caution
    > is to watch for a situation where nat would only occur in one direction.
    > There are frequently posts about this.
    >
    > "ae" <> wrote in message
    > news:B7Vdd.8590$...
    > > Hi all
    > >
    > > I can't find this information on Cisco.com. Here is the scenario. Hope
    > > someone can shed some light.
    > >
    > > Companies A & B want to establish a VPN tunnel (using Routers A & B).
    > >
    > > Router A has the IP address of 100.1.1.1 (external). Its internal

    network
    > > has a host (Host A) with a private address of 192.168.1.2.
    > >
    > > Router B has the IP address of 200.1.1.1 (external). Its internal

    network
    > > also has a host (Host B) with a private address of 192.168.1.2 (same
    > > address
    > > as Host A).
    > >
    > > Obviously, Companies A & B have identical IP address space. Good thing

    is
    > > that only Host A can initiate requests to Host B (application server).
    > > Host
    > > B are not allowed to initiate request to Host A.
    > >
    > > The requirements are these:
    > > 1. Traffic between Host A & B must be in VPN tunnel.
    > > 2. Host A can use Router A's overloaded external address. This way Host

    B
    > > sees Host A as having an address of 100.1.1.1 (Router A's address).
    > >
    > > Do Cisco routers support this kind of configuration?
    > >
    > > Thanks.
    > >
    > > Al
    > >
    > >

    >
    >


    Personally, I think you could accomplish your goal with a much better
    solution...

    Create tunnel interfaces on both routers and use an ipsec tunnel between
    them. At that point, this is just another interface. You can create
    individual nat addresses, use a pool or overload the tunnel interface. With
    the tunnel interfaces, you are free to use any addresses you like (recommend
    sticking with private address space) which will give you as many addresses
    as you need.

    My guess is that if the vpn is needed in the first place, then overloading
    won't work. Simply because you need to get a particular host on the other
    end. So, create static nat items for the ones you need to get to and either
    pool or overload the rest - both sides of course.

    This can become a difficult solution on the pix, but the IOS routers handle
    this solution very well.

    Hope that helps,

    Jim
     
    Scooby, Oct 22, 2004
    #3
  4. In article <2DYdd.5164$>,
    Scooby <> wrote:
    |> "ae" <> wrote in message
    |> news:B7Vdd.8590$...

    |> > Obviously, Companies A & B have identical IP address space.

    |> > The requirements are these:
    |> > 1. Traffic between Host A & B must be in VPN tunnel.
    |> > 2. Host A can use Router A's overloaded external address. This way Host B
    |> > sees Host A as having an address of 100.1.1.1 (Router A's address).

    |This can become a difficult solution on the pix

    The PIX handles the situation relatively cleanly.

    The old solution on the PIX was to use the 'alias' command.
    The 'alias' command had two different meanings, though, and
    has been functionally replaced by new options on static and nat
    commands, allowing a finer control.

    The new solution on the PIX would be to use "reverse nat" (also called
    "bidirectional nat"). On A, one would configure something like,

    static (outside, inside) 192.168.2.0 192.168.1.0 netmask 255.255.255.0 dns

    Then, to send to B's 192.168.1.N, the user would addres the packet
    to 192.168.2.N. As the packet was preparing to cross the outside
    interface, the destination IP would be mapped to the corresponding
    192.168.1.N IP before being sent over the tunnel to B. The host on
    B replies, the response comes through the tunnel, and A then
    maps the source address of the reply packet from 192.168.1.N to the
    corresponding 192.168.2.N IP before passing the packet on to the
    original inside computer. This completes the circuit.

    The 'dns' option on the end specifies that if A requests DNS
    resolution from a host beyond the outside interface (could be
    somewhere on the internet, could be somewhere on B's site),
    then if the DNS response contains any IPs in the 192.168.1.N range,
    then the PIX will alter the response to be 192.168.2.N instead.

    Thus, if there is a DNS server at B that returns 192.168.1
    IP addresses for B's hosts, the response will be altered so that
    the host at A is handed the right IP to use to get to the resource
    on B. If A has a DNS server for its own internal resources
    and that DNS server is in the 'inside' or is on any DMZ interface,
    and A isn't trying to resolve it's own IP addreses from something
    beyond the 'outside' interface, then the 192.168.1.* IP returned
    internally or from a DMZ will -not- be changed, and so will
    refer to A's resource with that IP.

    However, if the DNS servers for A and B are -both- behind
    the outside interface relative to A, then you must *not* use the
    'dns' option, or else the PIX will know whether any
    particular 192.168.1.* address was at A or B, and the PIX will just
    go ahead and translate them all as if they were at B. If you are
    trying to use overlapping IP ranges with DNS servers that return
    the internal 192.168.1.* IP addresses, then you can't do it with
    straight-forward DNS configuration and the 'dns' option if the
    DNS servers are both outside of 'A' and outside of 'B' as well.
    [If the DNS server for A is on the internet and the DNS server
    for B is inside B, then you should do the reverse-NAT trick at B instead
    of at A.]

    If the DNS servers for A and B are both outside relative to A and B
    then do not use the 'dns' option: instead, use DNS servers that can
    do "split views" (such as bind9), and have it return different
    answers depending on whether it sees that A or B are asking the
    question.

    (IOS runs into the same issues about placement of DNS servers.)

    So... on PIX you can often get the desired behaviour by simply
    adding a single 'static' to one of the two ends. That's a lot easier
    than creating pools and loopback interfaces and whatever else.
    --
    Caution: A subset of the statements in this message may be
    tautologically true.
     
    Walter Roberson, Oct 22, 2004
    #4
  5. ae

    PES Guest

    "Scooby" <> wrote in message
    news:2DYdd.5164$...
    > "PES" <NO*SPAMpestewartREMOVE**SUCKS> wrote in
    > message
    > news:41783052$...
    >> I don't think that will be a problem if the private ranges weren't
    >> overlapping. On packets from inside to outside, nat happens before

    > crypto.
    >> Therefore, you would simply specify the overloaded address as source in

    > the
    >> crypto acl and the private range is the destination.
    >>
    >> There is, however, more than one problem. First of all, before nat host
    >> a
    >> is sending from 192.168.1.2 to 192.168.1.2, the packet will never leave

    > the
    >> pc and certainly not be directed to the default gateway. If it were to

    > make
    >> it to the router, the router would see 192.168.1.x as a directed
    >> connected
    >> and therefore route back out the same interface thus missing the crypto

    > map.
    >>
    >> What you could do is overload on the external interface on router a and
    >> do

    > a
    >> static nat on router b to a different subnet. Fore example on router b
    >> statically nat 192.168.1.2 to 192.168.2.2. If it is already natted to a
    >> public you could use that. If you build your crypto acl to reflect the
    >> packets after the nat, all should be fine. The only thing I would
    >> caution
    >> is to watch for a situation where nat would only occur in one direction.
    >> There are frequently posts about this.
    >>
    >> "ae" <> wrote in message
    >> news:B7Vdd.8590$...
    >> > Hi all
    >> >
    >> > I can't find this information on Cisco.com. Here is the scenario. Hope
    >> > someone can shed some light.
    >> >
    >> > Companies A & B want to establish a VPN tunnel (using Routers A & B).
    >> >
    >> > Router A has the IP address of 100.1.1.1 (external). Its internal

    > network
    >> > has a host (Host A) with a private address of 192.168.1.2.
    >> >
    >> > Router B has the IP address of 200.1.1.1 (external). Its internal

    > network
    >> > also has a host (Host B) with a private address of 192.168.1.2 (same
    >> > address
    >> > as Host A).
    >> >
    >> > Obviously, Companies A & B have identical IP address space. Good thing

    > is
    >> > that only Host A can initiate requests to Host B (application server).
    >> > Host
    >> > B are not allowed to initiate request to Host A.
    >> >
    >> > The requirements are these:
    >> > 1. Traffic between Host A & B must be in VPN tunnel.
    >> > 2. Host A can use Router A's overloaded external address. This way Host

    > B
    >> > sees Host A as having an address of 100.1.1.1 (Router A's address).
    >> >
    >> > Do Cisco routers support this kind of configuration?
    >> >
    >> > Thanks.
    >> >
    >> > Al
    >> >
    >> >

    >>
    >>

    >
    > Personally, I think you could accomplish your goal with a much better
    > solution...
    >
    > Create tunnel interfaces on both routers and use an ipsec tunnel between
    > them. At that point, this is just another interface. You can create
    > individual nat addresses, use a pool or overload the tunnel interface.
    > With
    > the tunnel interfaces, you are free to use any addresses you like
    > (recommend
    > sticking with private address space) which will give you as many addresses
    > as you need.
    >
    > My guess is that if the vpn is needed in the first place, then overloading
    > won't work. Simply because you need to get a particular host on the other
    > end. So, create static nat items for the ones you need to get to and
    > either
    > pool or overload the rest - both sides of course.
    >
    > This can become a difficult solution on the pix, but the IOS routers
    > handle
    > this solution very well.
    >
    > Hope that helps,
    >
    > Jim
    >


    I agree, it is cleaner and easier to configure. I was just looking for an
    easy out on having to do source and destination nat or having to do source
    nat on both ends. My complaint with this is when you start getting complex
    with nat and ipsec, you have to be careful to make sure that the statics
    apply where you mean for them to or you break communication from the
    statically nat'd host to the internet or the vpn depending on the approach.

    The difficulty can go as far as actually getting the packet to the router on
    each end (with nat disabled). To overcome this, one could do source nat on
    both ends, or source and destination nat on one end. However, it must be
    said that if there are other static's that nat to public for the hosts in
    question, there will be unexpected results. If there are only dynamic
    translations on the hosts in questions, they will be over wrote by statics.
    This is important when implementing this so there can be a bypass method
    using a route-map to a non-nat'd interface or using port translation only on
    the static. Therefore, I wanted to use publicly nat'able addresses with the
    required translations. Packet filtering can be implemented to make this
    only availble from the ipsec encrypted traffic (and hide it from the world).
     
    PES, Oct 22, 2004
    #5
  6. ae

    ae Guest

    Thanks, guys, for the help.

    Do you know if Cisco.com has configuration samples with what we just
    discussed? I have not found any.

    Al
     
    ae, Oct 25, 2004
    #6
    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. Trond Hindenes
    Replies:
    0
    Views:
    1,179
    Trond Hindenes
    Jul 22, 2003
  2. Dejan Gambin
    Replies:
    0
    Views:
    764
    Dejan Gambin
    Oct 16, 2003
  3. Afshin

    NAT on DVB based scenario

    Afshin, Oct 22, 2003, in forum: Cisco
    Replies:
    0
    Views:
    408
    Afshin
    Oct 22, 2003
  4. Allan Wilson

    VPN, from nat without VPN to nat with it

    Allan Wilson, Jul 5, 2004, in forum: Cisco
    Replies:
    1
    Views:
    655
    Walter Roberson
    Jul 5, 2004
  5. sagooj2002
    Replies:
    0
    Views:
    1,114
    sagooj2002
    Apr 25, 2005
Loading...

Share This Page