WAAS with IPSEC or GRE tunnels

Hello,
I have a client with HQ and remote site, I need to implement WAAS between them.
issue is they are connected GRE over IPsec over MPLS WAAN, is there anything to take care about when implementing WAAS in GRE/IPSEC deployment.
Thanks & BR
Moamen

I would keep in mind the following things...
1. Interception - You have to ensure you intercept the traffic outside the tunnels, otherwise you won't get any compression. Hardware based switches like the Cat6K cannot use WCCP on tunnel interfaces. Software based routers can do interception on tunnel interfaces, but don't scale as much as the hardware assisted platforms.
2. Packet size - if you are getting excessive fragmentation, try lowering the Optimized MSS value on the WAEs to under what you need for headers. WAAS default is 1432.
Other then that, what you have is a pretty normal installation situation.
Thanks,
Dan

Similar Messages

  • IPsec over GRE tunnel's line protocol is down but able to ping the tunnel destination

    >>both routers are located in different countries and connected with ISP
    >>IPsec over GRE tunnel is configured on both the routers 
    >>tunnel's line protocol is down for both the ends but able to reach the tunnel destination with tunnel source
    >>Packet is not receiving on the router_1 and but could see packets are getting encrypting on the Router_2
    >>ISP is not finding any issue with their end 
    >>Please guide me how i can fix this issue and what need to be check on this ????
    ========================
    Router_1#sh run int Tunnel20
    Building configuration...
    Current configuration : 272 bytes
    interface Tunnel20
     bandwidth 2048
     ip address 3.85.129.141 255.255.255.252
     ip mtu 1412
     ip flow ingress
     delay 1
     cdp enable
     tunnel source GigabitEthernet0/0/3
     tunnel destination 109.224.62.26
    end
    ===================
    Router_1#sh int Tunnel20
    Tunnel20 is up, line protocol is up>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Keepalive is not set
      Hardware is Tunnel
      Description: *To CRPrgEIQbaghd01 - 2Mb GRE over Shared ISP Gateway*
      Internet address is 3.85.129.141/30
      MTU 17916 bytes, BW 2048 Kbit/sec, DLY 10 usec,
         reliability 255/255, txload 1/255, rxload 1/255
      Encapsulation TUNNEL, loopback not set
      Keepalive not set
      Tunnel source 195.27.20.14 (GigabitEthernet0/0/3), destination 109.224.62.26
       Tunnel Subblocks:
          src-track:
             Tunnel20 source tracking subblock associated with GigabitEthernet0/0/3
              Set of tunnels with source GigabitEthernet0/0/3, 32 members (includes iterators), on interface <OK>
      Tunnel protocol/transport GRE/IP
        Key disabled, sequencing disabled
        Checksumming of packets disabled
      Tunnel TTL 255, Fast tunneling enabled
      Tunnel transport MTU 1476 bytes
      Tunnel transmit bandwidth 8000 (kbps)
      Tunnel receive bandwidth 8000 (kbps)
      Last input 1w6d, output 14w4d, output hang never
      Last clearing of "show interface" counters 2y5w
      Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0
      Queueing strategy: fifo
      Output queue: 0/0 (size/max)
      5 minute input rate 0 bits/sec, 0 packets/sec
      5 minute output rate 0 bits/sec, 0 packets/sec
         1565172427 packets input, 363833090294 bytes, 0 no buffer
         Received 0 broadcasts (0 IP multicasts)
         0 runts, 0 giants, 0 throttles
         0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
         1778491917 packets output, 1555959948508 bytes, 0 underruns
         0 output errors, 0 collisions, 0 interface resets
         0 unknown protocol drops
         0 output buffer failures, 0 output buffers swapped out
    =============================
    Router_1#ping 109.224.62.26 re 100 sou 195.27.20.14
    Type escape sequence to abort.
    Sending 100, 100-byte ICMP Echos to 109.224.62.26, timeout is 2 seconds:
    Packet sent with a source address of 195.27.20.14
    Success rate is 92 percent (92/100), round-trip min/avg/max = 139/142/162 ms
    Router_1#
    ============================================
    Router_1#sh cry ip sa pe 109.224.62.26 | in caps
        #pkts encaps: 831987306, #pkts encrypt: 831987306, #pkts digest: 831987306
        #pkts decaps: 736012611, #pkts decrypt: 736012611, #pkts verify: 736012611
    Router_1#sh clock
    15:09:45.421 UTC Thu Dec 25 2014
    Router_1#
    ===================
    Router_1#sh cry ip sa pe 109.224.62.26 | in caps
        #pkts encaps: 831987339, #pkts encrypt: 831987339, #pkts digest: 831987339
        #pkts decaps: 736012611, #pkts decrypt: 736012611, #pkts verify: 736012611>>>>>>>>>>>>>>>>>>>>Traffic is not receiving from Router 2 
    Router_1#sh clock
    15:11:36.476 UTC Thu Dec 25 2014
    Router_1#
    ===================
    Router_2#sh run int Tu1
    Building configuration...
    Current configuration : 269 bytes
    interface Tunnel1
     bandwidth 2000
     ip address 3.85.129.142 255.255.255.252
     ip mtu 1412
     ip flow ingress
     load-interval 30
     keepalive 10 3
     cdp enable
     tunnel source GigabitEthernet0/0
     tunnel destination 195.27.20.14
    end
    Router_2#
    =======================
    Router_2#sh run | sec cry
    crypto isakmp policy 10
     authentication pre-share
    crypto isakmp key Router_2 address 195.27.20.14
    crypto isakmp key Router_2 address 194.9.241.8
    crypto ipsec transform-set ge3vpn esp-3des esp-sha-hmac
     mode transport
    crypto map <Deleted> 10 ipsec-isakmp
     set peer 195.27.20.14
     set transform-set ge3vpn
     match address Router_2
    crypto map <Deleted> 20 ipsec-isakmp
     set peer 194.9.241.8
     set transform-set ge3vpn
     match address Router_1
     crypto map <Deleted>
    Router_2#
    ====================================
    Router_2#sh cry ip sa pe 195.27.20.14 | in caps
        #pkts encaps: 737092521, #pkts encrypt: 737092521, #pkts digest: 737092521
        #pkts decaps: 828154572, #pkts decrypt: 828154572, #pkts verify: 828154572>>>>>>>>>>>>Traffic is getting encrypting from router 2 
    Router_2#sh clock
    .15:10:33.296 UTC Thu Dec 25 2014
    Router_2#
    ========================
    Router_2#sh int Tu1
    Tunnel1 is up, line protocol is down>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Down
      Hardware is Tunnel
      Internet address is 3.85.129.142/30
      MTU 17916 bytes, BW 2000 Kbit/sec, DLY 50000 usec,
         reliability 255/255, txload 1/255, rxload 1/255
      Encapsulation TUNNEL, loopback not set
      Keepalive set (10 sec), retries 3
      Tunnel source 109.224.62.26 (GigabitEthernet0/0), destination 195.27.20.14
       Tunnel Subblocks:
          src-track:
             Tunnel1 source tracking subblock associated with GigabitEthernet0/0
              Set of tunnels with source GigabitEthernet0/0, 2 members (includes iterators), on interface <OK>
      Tunnel protocol/transport GRE/IP
        Key disabled, sequencing disabled
        Checksumming of packets disabled
      Tunnel TTL 255, Fast tunneling enabled
      Tunnel transport MTU 1476 bytes
      Tunnel transmit bandwidth 8000 (kbps)
      Tunnel receive bandwidth 8000 (kbps)
      Last input 1w6d, output 00:00:02, output hang never
      Last clearing of "show interface" counters never
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 14843
      Queueing strategy: fifo
      Output queue: 0/0 (size/max)
      30 second input rate 0 bits/sec, 0 packets/sec
      30 second output rate 0 bits/sec, 0 packets/sec
         1881547260 packets input, 956465296 bytes, 0 no buffer
         Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
         0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
         1705198723 packets output, 2654132592 bytes, 0 underruns
         0 output errors, 0 collisions, 0 interface resets
         0 unknown protocol drops
         0 output buffer failures, 0 output buffers swapped out
    =============================
    Router_2#ping 195.27.20.14 re 100 sou 109.224.62.26
    Type escape sequence to abort.
    Sending 100, 100-byte ICMP Echos to 195.27.20.14, timeout is 2 seconds:
    Packet sent with a source address of 109.224.62.26
    Success rate is 94 percent (94/100), round-trip min/avg/max = 136/143/164 ms
    Router_2#
    =========================

    Hello.
    First of all, try to reset IPSec (clear crypto isakmp sa ..., clear crypto session ...).
    Configure inbound ACL on the router to match esp protocol and check if the packets arrive.
    Please provide full output "show crypto ipsec sa"
     from both sides.

  • Problem with a simple GRE tunnel

    Hello everyone:
    I have a problem with a simple GRE tunnel, and can not make it work, the problem lies in the instruction "tunnel source loopback-0" if I use this command does not work, now if I use "tunnel source <ip wan >" if it works, someone can tell me why?
    Thanks for your help
    Router 1: 2811
    version 12.4
    no service password-encryption
    hostname cisco2811
    no aaa new-model
    ip cef
    interface Loopback0
    ip address 2.2.2.2 255.255.255.255
    interface Tunnel0
    ip address 10.10.1.1 255.255.255.0
    tunnel source Loopback0
    tunnel destination 217.127.XXX.188
    interface Tunnel1
    ip address 10.10.2.1 255.255.255.0
    tunnel source Loopback0
    tunnel destination 80.32.XXX.125
    interface FastEthernet0/0
    description LOCAL LAN Interface
    ip address 192.168.1.254 255.255.255.0
    ip nat inside
    ip virtual-reassembly
    duplex auto
    speed auto
    interface FastEthernet0/1
    description WAN Interface
    ip address 195.77.XXX.70 255.255.255.248
    ip nat outside
    ip virtual-reassembly
    duplex auto
    speed auto
    ip forward-protocol nd
    ip route 0.0.0.0 0.0.0.0 195.77.XXX.65
    ip route 192.168.3.0 255.255.255.0 Tunnel0
    ip route 192.168.4.0 255.255.255.0 Tunnel1
    ip nat inside source route-map salida-fibra interface FastEthernet0/1 overload
    access-list 120 deny ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255
    access-list 120 deny ip 192.168.1.0 0.0.0.255 192.168.4.0 0.0.0.255
    access-list 120 permit ip 192.168.1.0 0.0.0.255 any
    route-map salida-fibra permit 10
    match ip address 120
    Router 2: 2811
    version 12.4
    service password-encryption
    ip cef
    no ip domain lookup
    multilink bundle-name authenticated
    username admin privilege 15 password 7 104CXXXXx13
    interface Loopback0
    ip address 4.4.4.4 255.255.255.255
    interface Tunnel0
    ip address 10.10.1.2 255.255.255.0
    tunnel source Loopback0
    tunnel destination 195.77.XXX.70
    interface Ethernet0
    ip address 192.168.3.251 255.255.255.0
    ip nat inside
    ip virtual-reassembly
    hold-queue 100 out
    interface ATM0
    no ip address
    no ip route-cache cef
    no ip route-cache
    no atm ilmi-keepalive
    dsl operating-mode auto
    interface ATM0.1 point-to-point
    ip address 217.127.XXX.188 255.255.255.192
    ip nat outside
    ip virtual-reassembly
    no ip route-cache
    no snmp trap link-status
    pvc 8/32
    encapsulation aal5snap
    ip route 0.0.0.0 0.0.0.0 ATM0.1
    ip route 192.168.1.0 255.255.255.0 Tunnel0
    ip nat inside source route-map nonat interface ATM0.1 overload
    access-list 100 permit ip 192.168.3.0 0.0.0.255 192.168.1.0 0.0.0.255
    access-list 120 deny ip 192.168.3.0 0.0.0.255 192.168.1.0 0.0.0.255
    access-list 120 permit ip 192.168.3.0 0.0.0.255 any
    route-map nonat permit 10
    match ip address 120

    Hello, thank you for the answer, as to your question, I have no connectivity within the tunnel, whether from Router 1, I ping 10.10.1.2 not get response ...
    Now both routers remove the loopback, and the interface tunnel 0 change the tunnel source to "tunnel source " tunnel works perfectly, the problem is when I have to use the loopback. Unfortunately achieved when the tunnel work, this will have to endure multicast, and all the examples found carrying a loopback as' source '... but this is a step back ..
    Tunnel0 is up, line protocol is up
    Hardware is Tunnel
    Internet address is 10.10.1.1/24
    MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
    reliability 255/255, txload 1/255, rxload 1/255
    Encapsulation TUNNEL, loopback not set
    Keepalive not set
    Tunnel source 2.2.2.2 (Loopback0), destination 217.127.XXX.188
    Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
    Tunnel TTL 255
    Fast tunneling enabled
    Tunnel transmit bandwidth 8000 (kbps)
    Tunnel receive bandwidth 8000 (kbps)
    Last input 09:04:38, output 00:00:19, output hang never
    Last clearing of "show interface" counters never
    Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
    Queueing strategy: fifo
    Output queue: 0/0 (size/max)
    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute output rate 0 bits/sec, 0 packets/sec
    0 packets input, 0 bytes, 0 no buffer
    Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
    0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
    11101 packets output, 773420 bytes, 0 underruns
    0 output errors, 0 collisions, 0 interface resets
    0 unknown protocol drops
    0 output buffer failures, 0 output buffers swapped out

  • IPsec over GRE in ASR 1000 with VRF

                       Hi
    I´m trying to configure IPsec over GRE tunnel between Cisco 819G remote router and ASR 1002 central router using crypto maps. Currently ASR router has two vrf´s (management vrf and EXTERNOS2 vrf) and in the future we are going to deploy different "virtual" routers from this box. I don´t know why it doesn´t work, tunnel interface doesn´t go up. Taking a view to debugs obtained from ASR router (debug crypto isakmp and debug crypto ipsecI see the following errors:
    Oct  3 13:11:33: IPSEC(validate_proposal_request): proposal part #1
    Oct  3 13:11:33: IPSEC(validate_proposal_request): proposal part #1,
      (key eng. msg.) INBOUND local= 10.255.68.246:0, remote= 10.200.25.106:0,
        local_proxy= 10.255.68.246/255.255.255.255/256/0,
        remote_proxy= 10.200.25.106/255.255.255.255/256/0,
        protocol= ESP, transform= NONE  (Transport),
        lifedur= 0s and 0kb,
        spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0
    Oct  3 13:11:33: Crypto mapdb : proxy_match
            src addr     : 10.255.68.246
            dst addr     : 10.200.25.106
            protocol     : 0
            src port     : 0
            dst port     : 0
    Oct  3 13:11:33: map_db_check_isakmp_profile profile did not match
    Oct  3 13:11:33: Crypto mapdb : proxy_match
            src addr     : 10.255.68.246
            dst addr     : 10.200.25.106
            protocol     : 0
            src port     : 0
            dst port     : 0
    Oct  3 13:11:33: map_db_check_isakmp_profile profile did not match
    Oct  3 13:11:33: map_db_find_best did not find matching map
    Oct  3 13:11:33: IPSEC(ipsec_process_proposal): proxy identities not supported
    Oct  3 13:11:33: ISAKMP:(35001): IPSec policy invalidated proposal with error 32
    Oct  3 13:11:33: ISAKMP:(35001): phase 2 SA policy not acceptable! (local 10.255.68.246 remote 10.200.25.106)
    anybody could help me to troubleshoot why it doesn´t work?
    I post you involved configuration sections from ASR and 819G routers
    B.R.

    Ops!! I forgot to paste involved routes from both devices.
    ASR router
    ip route vrf EXTERNOS2 10.200.24.0 255.255.248.0 10.255.68.245 tag 6
    ip route vrf EXTERNOS2 185.1.1.0 255.255.255.0 Tunnel21 tag 6          <--- c819G LAN network
    Cisco 819G
    ip route 0.0.0.0 0.0.0.0 Tunnel1
    ip route 10.255.68.246 255.255.255.255 Cellular0
    B.R.

  • Ipsec(tunnelmode)+gre+eigr

    is it possible to use ipsec(tunnelmode)+gre+eigrp at the sime time?

    The real question is not whether you are connected using a single physical interface at the central site. I have a customer who is currently using a single physical interface for about 90 GRE tunnels with no issue about split horizon. But these are traditional point to point GRE tunnels. If you connect to multiple remote locations with a multipoint GRE tunnel then there is an issue with EIGRP split horizon and you would need to turn off split horizon. If you do not disable split horizon the symptom is likely to be that all remotes can talk to the central site, the central site can talk to all remotes, but one remote will not be able to talk to other remotes.
    HTH
    Rick

  • GRE Tunnel on cisco 831

    Hi ,
    Who can tell me how to config ipsec over GRE tunnel when remote side useing dynamic ip !
    Thanks!

    Cisco has introduced a feature designed to do exactly what you are asking. You can configure an IPSec VPN over GRE tunnel where the remote has dynamic IP using the feature of Dynamic Multipoint VPN (DMVPN).
    The key concept here is that the remote side must initiate the tunnel to the central side. In the message requesting the tunnel the remote indicates what address the central should use as the tunnel destination.
    I have configured it in the lab and it worked pretty well. I have not yet used it in a production environment.
    This URL should help you get started with this:
    http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110ba1.html
    HTH
    Rick

  • Windows Replication RPC Problems with IPSec GRE Tunnel

    We have been having significant issue in troubleshooting random RPC errors with our directory controllers (MS AD 2008R2) and our distributed file shares.  Both services will randomly stop working, throwing RPC errors as the resulting cause.  We have been all over both Cisco and Microsoft forums in trying to troubleshoot this problem.  I'm trying to the Cisco forums first to see if anyone has any network layer thoughts as to best practices or ways to configure the tunnel.
    Our network is simple: two small branch offices connected to each other with two Cisco 2901 ISRs.  An IPSec GRE tunnel exists between both offices.  Interoffice bandwidth is approximately 10mbps.  Pings between offices work, remote desktop works most of the time, file transfers work, and DNS lookups work across both locations.  We really don't have a complicated environment, I'd think it wouldn't be too hard to set up.  But this just seems to be escaping me.  I can't think of anything at the network layer that would be causing problems but I was curious whether anyone else out there with knowledge of small office VPNs might be able to render some thoughts on the matter.
    Please let me know if there is anything further people need to see.  My next step is MS forums but I wanted to eliminate layer 3 first.
    Tunnel Config:
    crypto map outside_crypto 10 ipsec-isakmp
    set peer x.x.x.x
    set transform-set ESP-AES-SHA
    match address 102
    crypto ipsec df-bit clear
    interface Tunnel0
    bandwidth 10240
    ip address x.x.x.x x.x.x.x
    no ip redirects
    ip mtu 1420
    ip virtual-reassembly in
    zone-member security in-zone
    ip tcp adjust-mss 1375
    tunnel source GigabitEthernet0/0
    tunnel destination x.x.x.x
    crypto ipsec df-bit clear
    end

    Hi,
    Based on the third-party article below, you can setup VPN connection between Windows VPN client and Cisco firewall:
    Step By Step Guide To Setup Windows 7/Vista VPN Client to Remote Access Cisco ASA5500 Firewall
    What is the Windows server 2008 R2 for, a RADIUS server? If yes, maybe the links below would be helpful to you:
    RADIUS: Configuring Client VPN with Windows 2008 Network Policy Server (NPS) RADIUS Authentication
    Configuring RADIUS Server on Windows 2008 R2 for Cisco Device Logins
    RADIUS authentication for Cisco switches using w2k8R2 NPS
    Note: Microsoft is providing this information as a convenience to you. The sites are not controlled by Microsoft. Please make sure that you completely understand the risk before retrieving any suggestions from the above link.
    Best regards,
    Susie

  • IP routing utilizing Verizon private network (GRE tunnel) with remote cellular gateways

    Okay, I give up, and think I have done my due diligence (I have been engrossed and fascinated spending many more hours than allotted to try and learn some of the finer details).  Time for some advice.  My usual trade is controls engineering which generally require only basic knowledge of networking principals.  However I recently took a job to integrate 100 or so lift stations scattered around a county into a central SCADA system.  I decided to use cellular technology to connect these remote sites back to the main SCADA system.  Well the infrastructure is now in and it’s time to get these things talking.  Basic topology description is as follows:  Each remote site has an Airlink LS300 gateway.  Attached to the gateway via Ethernet is a system controller that I will be polling via Modbus TCP from the main SCADA system.  The Airlinks are provisioned by Verizon utilizing a private network with static IP's.  This private networks address is 192.168.1.0/24.  Back at the central office the SCADA computer is sitting behind a Cisco 2911.  The LAN address of the central office is 192.168.11.0/24.  The 2911 is utilizing GRE tunnels that terminate with Verizon.  The original turn up was done with another contractor that did a basic config of the router which you will find below.  As it stands now I am pretty confident the tunnels are up and working (if I change a local computers subnet to 255.255.0.0 I can surprisingly reach the airlinks in the field), but this is obviously not the right way to solve the problem, not to mention I was unable to successfully poll the end devices on the other side of the Airlinks.  I think I understand just about every part of the config below and think it is just missing a few items to be complete.  I would greatly appreciate anyone’s help in getting this set up correctly.  I also have a few questions about the set up that still don’t make sense to me, you will find them below the config.  Thanks in advance.
    no aaa new-model
    ip cef
    ip dhcp excluded-address 10.10.10.1
    ip dhcp pool ccp-pool
     import all
     network 10.10.10.0 255.255.255.248
     default-router 10.10.10.1 
     lease 0 2
    ip domain name yourdomain.com
    no ipv6 cef
    multilink bundle-name authenticated
    username cisco privilege 15 one-time secret 
    redundancy
    crypto isakmp policy 1
    encr 3des
    hash md5
     authentication pre-share
     group 2
    crypto isakmp key AbCdEf01294 address 99.101.15.99  
    crypto isakmp key AbCdEf01294 address 99.100.14.88 
    crypto ipsec transform-set VZW_TSET esp-3des esp-md5-hmac 
    mode transport
    crypto map VZW_VPNTUNNEL 1 ipsec-isakmp 
     description Verizon Wireless Tunnel
     set peer 99.101.15.99
     set peer 99.100.14.88
     set transform-set VZW_TSET 
     match address VZW_VPN
    interface Tunnel1
     description GRE Tunnel to Verizon Wireless
     ip address 172.16.200.2 255.255.255.252
     tunnel source 22.20.19.18
     tunnel destination 99.101.15.99
    interface Tunnel2
    description GRE Tunnel 2 to Verizon Wireless
     ip address 172.16.200.6 255.255.255.252
     tunnel source 22.20.19.18
     tunnel destination 99.100.14.88
    interface Embedded-Service-Engine0/0
     no ip address
     shutdown
    interface GigabitEthernet0/0
     description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$
     ip address 10.10.10.1 255.255.255.248
     shutdown
     duplex auto
     speed auto
    interface GigabitEthernet0/1
     ip address 192.168.11.1 255.255.255.0
     duplex auto
     speed auto
    interface GigabitEthernet0/2
     ip address 22.20.19.18 255.255.255.0
    duplex full
     speed 100
     crypto map VZW_VPNTUNNEL
    router bgp 65505
     bgp log-neighbor-changes
     network 0.0.0.0
     network 192.168.11.0
     neighbor 172.16.200.1 remote-as 6167
     neighbor 172.16.200.5 remote-as 6167
    ip forward-protocol nd
    ip http server
    ip http access-class 23
    ip http authentication local
    ip http secure-server
    ip http timeout-policy idle 60 life 86400 requests 10000
    ip route 0.0.0.0 0.0.0.0 22.20.19.19
    ip access-list extended VZW_VPN
     permit gre host 99.101.15.99 host 22.20.19.18
     permit icmp host 99.101.15.99 host 22.20.19.18
     permit esp host 99.101.15.99 host 22.20.19.18
     permit udp host 99.101.15.99 host 22.20.19.18 eq isakmp
     permit gre host 22.20.19.18 host 99.101.15.99
     permit gre host 22.20.19.18 host 99.100.14.88
    access-list 23 permit 10.10.10.0 0.0.0.7
    control-plane
    end
    So after spending countless hours analyzing every portion of this,  I think that adding one line to this will get it going (or at least closer).
    ip route 192.168.1.0 255.255.0.0 22.20.19.19
    That should allow my internal LAN to reach the Airlink gateways on the other side of the tunnel (I think)
    Now for a couple of questions for those that are still actually hanging around.
    #1 what is the purpose of the Ethernet address assigned to each tunnel?  I only see them being used in the BGP section where they are receiving routing tables from the Verizon side (is that correct?).  Why wouldn't or couldn't you just use the physical Ethernet address interface in its place (in the BGP section)?
    #2 is the config above correct in pointing the default route to the physical Ethernet address?  Does that force the packets into the tunnel, or shouldn’t you be pointing it towards the tunnel IP's (172.16.200.2)?  If the config above is correct then I should not need to add the route I described above as if I ping out to 192.168.1.X that should catch it and force it into the tunnel where Verizon would pick it up and know how to get it to its destination??
    #3 Will I need to add another permit to the VZW_VPN for TCP as in the end I need to be able to poll via Modbus which uses port 502 TCP.  Or is TCP implicit in some way with the GRE permit?
     I actually have alot more questions, but I will keep reading for now.
    I really appreciate the time you all took to trudge through this.  Also please feel free to point anything else out that I may have missed or that can be improved.  Have a great day!

    This post is a duplicate of this thread
    https://supportforums.cisco.com/discussion/12275476/proper-routing-lan-through-verizon-private-network-gre-airlink-gateways
    which has a response. I suggest that all discussion of this question be done through the other thread.
    HTH
    Rick

  • When do i have to use a gre over ipsec tunnel? i have heard that when i m using a routing protocol and vpn site to site i need a gre tunnel

    i have configured a network with ospf and a vpn site to site without gre tunnel and it works very well. I want to know, when do i have to use gre tunnel over ipsec

    Jose,
    It sounds like you currently have an IPsec Virtual Tunnel Interface (VTI) configured. By this, I mean that you have a Tunnel interface running in "tunnel mode ipsec ipv4" rather than having a crypto map applied to a physical interface. In the days before VTIs, it was necessary to configure GRE over IPsec in order to pass certain types of traffic across an encrypted channel. When using pure IPsec with crypto maps, you cannot pass multicast traffic without implementing GRE over IPsec. Today, IPsec VTIs and GRE over IPsec accomplish what is effectively the same thing with a few exceptions. For example, by using GRE over IPsec, you can configure multiple tunnels between two peers by means of tunnels keys, pass many more types of traffic rather than IP unicast and multicast (such as NHRP as utilized by DMVPN), and you can also configure multipoint GRE tunnels whereas VTIs are point to point.
    Here's a document which discusses VTIs in more depth: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_vpnips/configuration/xe-3s/sec-sec-for-vpns-w-ipsec-xe-3s-book/sec-ipsec-virt-tunnl.html#GUID-A568DA9D-56CF-47C4-A866-B605804179E1
    HTH,
    Frank

  • GRE tunnel through asa no pptp, l2tp, ipsec

    Hello!
    can't understand how to configure GRE tunnel through ASA
    i have one router with public ip, connected to internet
    ASA 8.4 with public ip connected to internet
    router with private ip behind ASA.
    have only one public ip on ASA with /30 mask
    have no crypto
    have network behind ASA and PAT for internet users.
    can't nat GRE? cause only TCP/UDP nated(?)
    with packet-tracer i see flow already created but tunnel doesn't work

    A "clean" way would be to use a protocol that can be PATted. That could be GRE over IPSec. With that you have the additional benefit that your communication is protected through the internet.
    Don't stop after you've improved your network! Improve the world by lending money to the working poor:
    http://www.kiva.org/invitedby/karsteni

  • Encrypted GRE Tunnel with RIP on a SRW527w??

    Hi All,
    Is it possible to configure an IPSEC GRE tunnel with RIP on an SRP527w? I see RIP, GRE & IPSEC are all possible.. But I'm not sure about them all together securing the GRE tunnel??
    See below. I basically want to do this with the SRW routers not native IOS. Single head end hub & spoke.
    http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a008073a0c5.pdf
    Thanks a lot
    Matt                  

    On a much smaller scale of course!

  • DMVPN GRE with IPSEC fragmentation

    When configuring our tunnel we get an error message indicating that the MTU is greater than the transport value 1376, fragmentation will occur (see below).  We are using transport mode and using the recommended MTU settings of 1400 bytes.  Could this be causing excessive fragmentation and affecting latency and user experience?
    ro1-91309(config)#interface Tunnel2
    service_policy on dynamic interface is not allowed if there is fair-queue configured on main interface
    ro1-91309(config-if)# description GRE tunnel interface to Tempe
    ro1-91309(config-if)# bandwidth 1500
    ro1-91309(config-if)# ip address x.x.x.x.x
    ro1-91309(config-if)# ip mtu 1400
    %Warning: IP MTU value set 1400 is greater than the current transport value 1376, fragmentation may occur
    ro1-91309(config-if)# ip hello-interval eigrp 65100 10
    ro1-91309(config-if)# ip hold-time eigrp 65100 40
    ro1-91309(config-if)# ip flow ingress
    ro1-91309(config-if)# ip flow egress
    ro1-91309(config-if)# ip pim sparse-mode
    ro1-91309(config-if)# ip nat outside
    ro1-91309(config-if)# ip nhrp authentication cisco
    ro1-91309(config-if)# ip nhrp map 10.2.0.1 x.x.x.x
    ro1-91309(config-if)# ip nhrp map multicast x.x.x.x
    ro1-91309(config-if)# ip nhrp network-id 1001
    ro1-91309(config-if)# ip nhrp holdtime 600
    ro1-91309(config-if)# ip nhrp nhs 10.2.0.1
    ro1-91309(config-if)# ip nhrp registration timeout 30
    ro1-91309(config-if)# ip virtual-reassembly in
    ro1-91309(config-if)# zone-member security TRUST
    ro1-91309(config-if)# ip tcp adjust-mss 1360
    ro1-91309(config-if)# ip summary-address eigrp 65100 10.8.80.0 255.255.255.0 5
    ro1-91309(config-if)# load-interval 30
    ro1-91309(config-if)# if-state nhrp
    ro1-91309(config-if)# qos pre-classify
    ro1-91309(config-if)# tunnel source FastEthernet0/1
    ro1-91309(config-if)# tunnel destination x.x.x.x
    ro1-91309(config-if)# tunnel key 1001
    ro1-91309(config-if)# tunnel protection ipsec profile iGBN
    ro1-91309(config-if)# max-reserved-bandwidth 100
    service_policy on dynamic interface is not allowed if there is fair-queue configured on main interface
    ro1-91309(config-if)# hold-queue 4096 in
    ro1-91309(config-if)# hold-queue 4096 out
    ro1-91309(config-if)#end
    Crypto settings
    crypto isakmp policy 1
    encr aes
    hash md5
    group 5
    crypto isakmp invalid-spi-recovery
    crypto isakmp keepalive 30 12
    crypto ipsec security-association replay window-size 1024
    crypto ipsec transform-set iGBN esp-aes esp-md5-hmac
    mode transport
    crypto ipsec profile iGBN
    set transform-set iGBN

    You should be good with this configuration -
    Here is the explaination-
    When an IP packet has been split into two fragments and encapsulated by GRE. In this case IPsec will see two independent GRE + IP packets. Often in a default configuration one of these packets will be
    large enough that it will need to be fragmented after it has been encrypted. The IPsec peer will have to reassemble this packet before decryption. This "double fragmentation" (once before GRE and again after IPsec) on the sending router increases latency and lowers throughput. Also, reassembly is process-switched, so there will be a CPU hit on the receiving router whenever this happens. This situation can be avoided by setting the "ip mtu" on the GRE tunnel interface low enough to take into account the overhead from both GRE and IPsec (by default the GRE tunnel interface "ip mtu" is set to the outgoing real interface MTU - GRE overhead bytes).

  • GRE Tunnel/NAT with multiple subnets and interfaces

    So, I am not sure if we are trying to accomplish too many things at once and what we are attempting to do is not possible or if we are missing something in our configurations...
    Here is the situation...
    We are migrating some equipment between datacenters.  The equipment only a has a /27 worth of IP space assigned to it so we cannot simply "move" the IP space to the new datacenter.  Further because we have several VPNs terminated in the old IP space that originate from devices we do not directly control and are essential in continuing to provide service, it was/is difficult to magically update some DNS entries and change IP addresses overnight.  The last twist in this puzzle is that at the new datacenter, we will deploying some new equipment that will be in a separate subnet (with a separate Windows AD structure) but sharing the new public IP space we have in the new datacenter.
    We thought using a GRE tunnel, some trunks, and a bunch of NATs would make the whole process easy and we tested ti in a lab and everything SEEMED to work.  However, when we performed the move we ran into an odd issue that we were unable to figure out and had to go back to a failsafe configuration that has the essentials up and running, but the environment is not running in an ideal way for us to gradually transition as we would like.
    Essentially what we had/have and how it was configured is as follows:
    Site A
    Edge Router - x.x.x.x /24 BGP announcement
    x.x.x.y/27 that is within the /24 that we need at site b
    GRE tunnel configuration
    interface tunnel0
      ip address 10.x.x.1 255.255.255.252
      tunnel source <router edge IP>
      tunnel destination <site b router edge ip>
      keepalive 10 3
    static route for site a public ip to bring it to site b via GRE tunnel
    ip route x.x.x.y 255.255.255.224 10.x.x.2
    Site B
    Edge Router - y.y.y.y /24 BGP announcement
    Similar GRE tunnel configuration (tunnel comes out and works so don't think issue is here)
    2 Vlans (1 for site a ip space, 1 for site b ip space)
    int vlan 50
    ip address x.x.x.1 /27
    int vlan 51
    ip address y.y.y.129 /25
    Trunk port for the VLANs going down to an ASA
    int g1/1
      swi mode trunk
      swi trunk native vlan 51
      swi tru all vlan 50,51
      swi tru en dot1q
    Then on the ASA, I have 2 physical interfaces for 4 logical interfaces (outside, outsideold, inside, insideold)
    int e0/0
     nameif outside
     sec 0
     ip address y.y.y.130 /25
    int e0/0.50
     nameif outsideold
     sec 0
     ip address x.x.x.2 /27
     vlan 51
    int e0/1
      nameif inside
      sec 100
      ip address 192.168.y.1 /24
    int e0/1.60
      nameif insideold
      sec 100
      ip address 192.168.x.1 /24
      vlan 60
    A static route using the new ip space on the native outside interface...
    route 0 0 y.y.y.129
    And then I have some nat rules which is where I think things go a little haywire...
    object network obj-y.y.y.0-24
      subnet y.y.y.0 255.255.255.0
     nat (inside,outside) dynamic interface
    object network obj-x.x.x.0-24
      subnet x.x.x.0 255.255.255.0
     nat (insideold,outside) dynamic interface
    object network obj-y.y.y.135-160
      range y.y.y.135 y.y.y.160
    object network obj-192.168.y.135-160
      range 192.168.y.135 192.168.y.160
      nat (inside,outside) static obj-y.y.y.135-160
    object network obj-x.x.x.10-20
      range x.x.x.10 x.x.x.20
    object network obj-192.168.x.10-20
      range 192.168.x.10 192.168.x.20
      nat (insideold,outsideold) static obj-x.x.x.10-20
    From some debugging and looking at packet-tracer, I found out I left out the below which was needed to properly nat traffic as it leaves the outside interface (when the default sends the traffic)
    object network obj-192.168.x.10-20-2
      range 192.168.x.10 192.168.x.20
      nat (insideold,outside) static obj-x.x.x.10-20
    There are / were a bunch of other nat exemptions for the VPNs and specific external routes to ensure all vpn traffic exited the "outsideold" interface which is where all the existing tunnels were terminated.
    Everything appeared to be working great as all the VPN tunnels came up perfectly as expected and traffic appeared to be flowing, except for some of the most important traffic.  The following was what was observed:
    1.  Any traffic using the dynamic NAT (ie...a machine with IP x.x.x.200 or y.y.y.20) would connect to the internet perfectly and work fine using the "new interface ip".
    2.  Any traffic in the "new range" using a one to one nat worked perfectly (ie y.y.y.140).  Internet would work etc and nat translation would properly occur and everything could connect fine as expected.
    3.  ICMP packets to "old ip range" flowed perfectly fine to one to one nat IP (ie I could ping x.x.x.20 from outside) and likelise I could ping anywhere on the internet from a machine with a static natted ip.
    4.  Heres the butt...no traffic other than ICMP would reach these machines with static ips.  Same range, same subnet as ones using the dynamic port translation that worked perfectly.  Do not understand why this was / is the case and this is what I am seeking a solution to.  I have attempted the following troubleshooting steps without success:
    A. Confirmed MTU size was not an issue with the GRE tunnel.  2 methods, one plugging to edge router and using the "outsideold" ip space works perfectly and 2 if I assign outsideold ip space to "outside" interface, everything nats fine.
    B. Ran packet-tracer, all results show "allow" as if I should be seeing the packets.
    C. Confirmed local windows machine firewall was off and not blocking anything.
    D. Reviewed logs and observed SYN timeouts and TCP teardowns as if the firewall is not getting a response and this is where I am stumped.  There is no path around the firewall so asymmetric routing should not be an issue and if that was the problem it should not work when the "outsideold" ip space is assigned and natted from the "outside" interface, but it does.  Packet-tracer shows proper nat translations occurring and there is definitely proper routing along the path for stuff to return to the network or ICMP would not work (IE I can ping www.google.com but not open the web page).
    So what simple piece of the nat configuration am I overlooking because I cannot possible wrap my head around it being anything else.
    Any suggestions / lessons would be greatly appreciated.

    is this still a problem?

  • DIscussion on GRE Tunnel IPSec VPN

    I am looking for some good discussion topics on GRE Tunnel / IPSec / VPN for a beginner. I am sure there will be some good articles on Cisco Site. Can someone please point me some of these articles
    Alphonse

    this url should be a good one for your
    https://learningnetwork.cisco.com/docs/DOC-15048#comment-30627
    which helps in configuring,verifying and troubleshooting.

  • OSPF with ipsec VTI interface goes down before dead timer.

    I have a strange issue that OSPF will initially start working, hellos are exchanged both ways but then after about 3 – 6 hellos one of the sides stops getting them and the ipsec VTI tunnel drops on router A even before the dead timer reaches 0. Is this default behavior, when OSPF is over a VTI interface if it doesn’t receive hellos is drops the tunnel?
    I’m at a loss as to what is going on since it looks like only one neighbor stops receiving hellos, router A, for a brief period of time. This VTI tunnel is going over another provider’s FW and they have assured me the tunnel destination/source ips are wide open they also sent me the ACL and I can verify this. The weird thing is if I enable EIGRP it works great with no issues. On router B I am using the same source/ip unnumbered  interface on multiple VTI tunnels to to other destinations but this shouldn’t cause any issues I don’t think. I have never had an issue like this and from what I can tell the router A just stops briefly getting hellos after 3 – 6 initial hellos and drops the protocol on the VTI interface. If I set the dead timer on router A long enough it will stop receiving hellos but stay up and then after a while you get “LOADING to FULL” as the hellos start coming in again.  Again the tunnel goes over a cisco 800 which I have no control over it and a potential FW before that but I saw the ACL and ip is being allowed. I was thinking this could be a trolling issue on the FW but it doesn’t explain why EIGRP works.  FYI I was having a recursive routing issue before but I have since fixed that and the issue still continues.
    ********  it turns out that i was using the same source ip on multiple tunnels. IPsec would get confused with packets coming in and would deliver packets to the wrong tunnel interface. This was solved but using the key command with a different key number on each set of tunnels with the shared profile command
    "If more than one mGRE tunnel is configured on a router that use the same tunnel source address, the shared keyword must be added to the tunnel protection command on all such tunnel interfaces. Each mGRE tunnel interface still requires a unique tunnel key, NHRP network-ID, and IP subnet address. This is common on a branch router when a dual DMVPN cloud topology is deployed. "
    Router A:
    router ospf 1
    router-id 10.213.22.2
    passive-interface default
    network x.x.97.26 0.0.0.0 area 0
    interface Tunnel1
    ip unnumbered GigabitEthernet0/1
    ip virtual-reassembly in
    ip tcp adjust-mss 1398
    ip ospf network point-to-point
    load-interval 30
    tunnel source GigabitEthernet0/1
    tunnel mode ipsec ipv4
    tunnel destination x.x.173.109
    tunnel path-mtu-discovery
    tunnel protection ipsec profile VTI-to-NB
    router B:
    router ospf 1
    router-id 172.17.2.6
    priority 1
    redistribute static subnets route-map Lan-static-RM
    passive-interface default
    no passive-interface Tunnel1
    no passive-interface Tunnel4
    no passive-interface Tunnel5
    network x.x.173.109 0.0.0.0 area 0
    network 172.17.2.6 0.0.0.0 area 0
    network 192.168.1.47 0.0.0.0 area 0
    interface Tunnel4
    ip unnumbered GigabitEthernet0/2
    ip virtual-reassembly in
    ip tcp adjust-mss 1398
    ip ospf network point-to-point
    load-interval 30
    tunnel source GigabitEthernet0/2
    tunnel mode ipsec ipv4
    tunnel destination x.x.97.26
    tunnel path-mtu-discovery
    tunnel protection ipsec profile VTI_NB_to_dorrance_prv
    end
    thanks P

    Disclaimer
    The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
    Liability Disclaimer
    In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
    Posting
    I haven't studied your config, but I can tell you I have production environment using OSPF across VTI  (and GRE, and GRE/IPSec and DMVPN) tunnels without issue.  I.e. so OSPF can be okay with VTI tunnels.

Maybe you are looking for