GRE/IPSEc hub and spokes question

Discussion in 'Cisco' started by Bancal, Jan 27, 2005.

  1. Bancal

    Bancal Guest


    I have two Cisco 1760 routers in headquarteers which are connected via
    GRE/IPSec tunnels with branch offices routers (they are Cisco 1760
    too)located in other cities.
    These two main office routers are connected to two different ISPs and
    GRE/IPSec VPNs connected to each brunch site router are configured on
    each main office router. This was made to provide fault tolerance. In
    normal conditions VPNs work on a single headquarteers router connected
    to the 1st ISP. If the link to 1st ISP becomes dead I direct VPN
    traffic to use the second headquarteeers router by changing static
    routes on both headquarteers router and brunch office routers.

    Everything was fine until the last few mounths when our ISP started to
    perform network equipment maintaince almost every week and it annoys us
    very much since it disrupts network connectivity.
    In this case I intended to use EIGRP as dynatic routing protocol
    instead of changing static routes in a case of link failure.
    I configured EIGRP on every router and in a case of link failure it
    works pretty well, I tested it.
    But implementing a dynamic routing on my network exerted an issue.
    I can pretty well ping hosts located in brunch offices's networks, but
    TCP sessions (SMTP, POP3, AD) drop unexpectedly.
    I presume that I did somethng wrong when configuring hub and spoke
    IPSec VPNs.
    Here are my questions

    1. Should I use transport or tunnel IPSec mode when configuring
    GRE/IPSec. I tested both modes and it's seems to me there's no
    difference in this case.
    2. Then configuring crypto map on a spoke router should I configure it
    like this

    crypto map Map1 10 ipsec-isakmp
    set peer x.x.x.x <- hub 1
    set peer y.y.y.y <- hub 2
    set transform-set cipher
    match address 110

    or like this

    crypto map Map1 10 ipsec-isakmp
    set peer x.x.x.x
    set transform-set cipher
    match address 110
    crypto map Map2 20 ipsec-isakmp
    set peer y.y.y.y
    set transform-set cipher
    match address 120

    Thank you in for your answers in advance.
    Bancal, Jan 27, 2005
    1. Advertisements

  2. Question1:
    It depends what you want to encrypt. There are a few differences, but
    the most noticeable is that Transport mode used the original IP header,
    where Tunnel mode creates a new header.
    Here is a couple of pictures to explain the difference:
    The Second Crypto Map option is the better. For crypto map entries
    created with the crypto map map-name seq-num ipsec-isakmp command, you
    can specify multiple peers by repeating this command. The peer that
    packets are actually sent to is determined by the last peer that the
    router heard from (received either traffic or a negotiation request
    from) for a given data flow. If the attempt fails with the first peer,
    Internet Key Exchange (IKE) tries the next peer on the crypto map list.
    Daniel Prinsloo -, Jan 27, 2005
    1. Advertisements

  3. Bancal

    Bancal Guest

    I know that.
    But here
    Cisco uses tunnel mode when configuring GRE/IPSEC
    and in this sample config
    transport mode is used and that puzzles me.

    Aha, I've got it.
    Bancal, Jan 27, 2005
  4. I generally use Tunnel mode if I have to transport a private address
    space over the Internet and Transport mode if the user are using
    registered addresses.
    Just my 10c worth.
    Daniel Prinsloo -, Jan 27, 2005
  5. Cause you are using GRE I would prefere transport mode. The GRE protocol
    already adds a new ip header which hides the private header. If you
    use transport mode you will get a third header which usualy will carry
    the same IP addresses as the GRE header.
    Helmut Ulrich, Jan 27, 2005
  6. Bancal

    RobO Guest

    Hi Bancal!

    I have come to similar problems and found that bumping the TCP maximum
    segment size down a bit sorted it out
    You can play around with the number to see at what point it stops
    passing tcp traffic.

    On your tunnel interfaces on either side do a "ip tcp adjust-mss 1420"
    Play around with the figure and see if this helps.
    I only use 1420 as a reference so try from higher and work your way
    You could even try reducing the mtu on the tunnel interfaces as well.

    Also am I to understand that you are trying to do a DMVPN with
    If so you dont need crypto map statements just set up a crypto ipsec
    profile and let the NHRP to the rest for you.
    Ofcourse this does depend on using a certain version of IOS. 12.2(15)
    or later please someone correct me if Im wrong.


    RobO, Jan 27, 2005
    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.