One remote network - two VPN tunnels.???

Discussion in 'Cisco' started by brychan, Jul 17, 2006.

  1. brychan

    brychan Guest

    Hi everyone. I'm a bit of a newbie to VPN so any help will be greatly
    appreciated. I need to find out if it is possible, using 3015 VPN
    Concentrators, to have traffic from one network routed across two
    different tunnels to two different, but related remote networks. Eg,
    traffic from the network 10.15.11.0 would go down one tunnel to get to
    10.15.0.0 and down another tunnel to get to 10.16.0.0. The hitch is
    that on the remote side, traffic can route between 10.15.0.0 and
    10.16.0.0. Thanks in advance
     
    brychan, Jul 17, 2006
    #1
    1. Advertising

  2. In article <>,
    brychan <> wrote:
    >Hi everyone. I'm a bit of a newbie to VPN so any help will be greatly
    >appreciated. I need to find out if it is possible, using 3015 VPN
    >Concentrators, to have traffic from one network routed across two
    >different tunnels to two different, but related remote networks.


    Yes.

    >Eg,
    >traffic from the network 10.15.11.0 would go down one tunnel to get to
    >10.15.0.0 and down another tunnel to get to 10.16.0.0. The hitch is
    >that on the remote side, traffic can route between 10.15.0.0 and
    >10.16.0.0. Thanks in advance


    How the remote end routes the network is only of interest if it
    interferes with the proper return of packets.

    [See, however, the notes below.]


    In IPSec, there are two different levels that might be referred
    to as "tunnels".

    When two peers connect to each other, they negotiate a "isakmp phase 1"
    tunnel that authenticates the peers and communicate various options,
    and after that is used mostly to securely build the other level of
    tunnels. Phase 1 does not carry payload data: it carries information
    -about- the payload tunnels.

    When there is data (payload) to communicate via the peers, a "phase 2"
    tunnel is built. Each of those payload tunnels is known as a
    "security association" (SA). You can have a number of different
    Security Associations within one peer-to-peer tunnel. Typically
    in IPSec, a different Security Association is built for each
    combination of source and destination.

    For example, peer X might be communicating with peer Y, and within the
    single phase 1 tunnel between them, there might be one Security
    Association for all traffic from 10.15.11.0/24 to 10.16.0.0/16, and a
    different Security Association for traffic from 10.15.11.0/24 to
    10.15.174.0/24. If there was a second network at X, say 10.15.8.0/24,
    then traffic from it to 10.16.0.0/16 would probably go over a different
    Security Association.

    Essentially each specified source (which might be a complete subnet or
    might be a single host) would use a different Security Association for
    each specified destination (which might be a complete subnet or might
    be a single host).

    IPSec does *not* attempt to be "smart" about re-using Security
    Associations: if you had for some reason configured a distinct
    source of host 10.15.11.98 and there was some traffic to go to
    10.16.0.0/16 and there was an active Security Association between
    10.15.11.0/24 and 10.16.0.0/16, then IPSec would still go ahead
    and build a distinct Security Association for the 10.15.11.98 ->
    10.16.0.0/16 traffic. Maybe ;-( What it does for new traffic
    is run *in order* through the list of rules of what traffic flows are
    permitted, and determines which rule applies, and each distinct rule
    active results in a different Security Association. So if the rule
    about 10.15.11.98 -> 10.16.0.0/16 happened to occur before the
    rule about 10.15.11.0/24 -> 10.16.0.0/16 then the more specific rule would
    sit inactive with no corresponding Security Association built until
    there happened to be traffic matching it, which would trigger building
    the more specific Security Association. If, however, the rule
    about 10.15.11.98 -> 10.16.0.0/16 happened to occur after the
    rule about 10.15.11.0/24 -> 10.16.0.0/16 then the more specific rule would
    never be reached.

    If the two ends do not happen to have the exact same trigger conditions
    in the exact same order, the two ends can end up disagreeing about
    which Security Association to use for particular traffic, and Then
    You Have A Problem.


    In your question, you indicated that one of the tunnels would
    carry traffic from 10.15.11.0 to 10.15.0.0, but you did not indicate
    the "width" of the destination. If the 10.15.0.0 was intended to
    indicate 10.15.0.0/24 then there is no problem, but if you are trying
    to use a tunnel from 10.15.11.0/24 to 10.15.0.0/16 then you are
    likely going to have routing difficulties: when the far end of the
    tunnel sees traffic destined for 10.15.11.0/24, how is it to know
    whether to send that traffic "inward" to the internal 10.15.0.0/16
    network, or "outward" to the 10.15.11.0/24 network at the peer?
    It is tricky to configure tunnels between overlapping subnets, and
    it should be avoided as much as practical. You would probably run
    into less grief by renumbering every host in 10.15.11.0/24 to
    10.17.11.0/24 to avoid the overlap, then you would run into attempting
    to get the tunnels to work properly with the overlap in place.


    Anyhow, summarizing what I was talking about earlier: you asked
    for having different "tunnels". That is handled automatically if
    you have different peers (VPN devices) for the two different
    destinations: in that case, different Phase 1 and Phase 2 tunnels would
    be used. If both flows are going to the same peer, then in
    a technical sense of the word "tunnel", different tunnels would
    be used for the two flows if the rules distinguish between the
    two destinations, thus resulting in different Security Associations
    (Phase 2 tunnels) being used for the two flows. Different Security
    Associations that are within the same Phase 1 tunnel will use different
    encryption session keys, so if you managed to break the encryption
    security for one of the Security Associations, the other would remain
    intact. [On the other hand, if you have technology sufficient to break
    the encryption on individual Security Associations, you'd probably
    attack the Phase 1 process and track the session keys of the
    Security Associations as they got built...]
     
    Walter Roberson, Jul 17, 2006
    #2
    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. This Old Man

    telnet through two VPN tunnels?

    This Old Man, Oct 17, 2003, in forum: Cisco
    Replies:
    1
    Views:
    504
    Walter Roberson
    Oct 17, 2003
  2. Brian Ipsen
    Replies:
    10
    Views:
    8,946
    Brian Ipsen
    Feb 25, 2004
  3. ljorg
    Replies:
    0
    Views:
    521
    ljorg
    Nov 22, 2006
  4. philbo30
    Replies:
    1
    Views:
    691
    Walter Roberson
    Apr 12, 2007
  5. mayureshjo

    One remote network - two VPN tunnels on cisco ASA

    mayureshjo, Mar 6, 2009, in forum: Computer Support
    Replies:
    0
    Views:
    545
    mayureshjo
    Mar 6, 2009
Loading...

Share This Page