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 (external). Its internal network
    has a host (Host A) with a private address of

    Router B has the IP address of (external). Its internal network
    also has a host (Host B) with a private address of (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 (Router A's address).

    Do Cisco routers support this kind of configuration?


    ae, Oct 21, 2004
    1. Advertisements

  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 to, 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 to 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.
    PES, Oct 21, 2004
    1. Advertisements

  3. ae

    Scooby Guest

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

    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,

    Scooby, Oct 22, 2004
  4. |>
    |> > 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 (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) netmask 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

    (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.
    Walter Roberson, Oct 22, 2004
  5. ae

    PES Guest

    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
  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.

    ae, Oct 25, 2004
    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.