Tunnel between two 887s works great, but now I want to encrypt (15.x)

[jimwillsher]

Hi

I have set up a tunnel bewteen two Cisco 887s across the internet. it works fine, but now I want to encrypt it but I'm not getting very far. These are the useful bits of the config:

R1 (LAN 192.168.7.x/24, WAN 82.69.1.37)

interface Tunnel0
 ip address 172.16.1.1 255.255.255.0
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel source 82.69.1.37
 tunnel destination 82.69.10.202

ip access-list extended acl-NAT-Ranges
    deny ip 192.168.7.0 0.0.0.255 192.168.3.0 0.0.0.255
    permit ip 192.168.7.0 0.0.0.255 any

ip route 192.168.3.0 255.255.255.0 172.16.1.2

R2 (LAN 192.168.3.x/24, WAN 82.69.10.202)

interface Tunnel0
 ip address 172.16.1.2 255.255.255.0
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel source 82.69.10.202
 tunnel destination 82.69.1.37

ip access-list extended acl-NAT-Ranges
    deny ip 192.168.3.0 0.0.0.255 192.168.7.0 0.0.0.255
    permit ip 192.168.3.0 0.0.0.255 any

ip route 192.168.7.0 255.255.255.0 172.16.1.1

All works fine, I can ping devices on the other system and I can map network drives to remote servers etc.

But...I want to add some security. I have tried various things to add encryption, e.g.:

crypto isakmp key PASS address 82.69.1.37

crypto ipsec transform-set TS esp-3des esp-md5-hmac
                mode transport

crypto ipsec profile protect-gre
                set security-association lifetime seconds 86400
                set transform-set TS

crypto isakmp policy 1
                encr 3des
                hash md5
                authentication pre-share
                group 2
                lifetime 86400

int Tunnel0
               tunnel protection ipsec profile protect-gre

tunnel mode ipsec ipv4

(plus the opposite for the other router).

However as soon as I add the command:

int Tunnel0
                tunnel protection ipsec profile protect-gre

or

int Tunnel0
                tunnel mode ipsec ipv4

I can no longer ping.

I'm not after NASA-grade encryption, I just want something simple. Most of the google articles I can find are quite old and the configurations give me errors about GDOI etc.

Many thanks to anyone who can assist.

Jim

[Francesco Molino]

Hi

Your config should be fine based on your input.

Could you share your exact config to see you've done a mistake?

Could you also issue those 2 commands and drop the output?

 - show cryp isakm sa

 - show cryp ipsec sa

Thanks

PS: Please don't forget to rate and mark as correct answer if this answered your question.

Thanks

[jimwillsher]

Many thanks for your reply.

I have uploaded four entire configs (except for passwords; IPs and ACLs are real), one for each site with the tunnel and one for each site after loading the crypto commands. Before adding crypto, the tunnel is up:

LaminatesFibre#ping 192.168.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/44/48 ms
LaminatesFibre#

but after adding crypto, it's down:

LaminatesFibre#ping 192.168.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
LaminatesFibre#

Finally, here's the output from the two commands on one site, after adding the crypto:

LaminatesFibre#show cryp isakm sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
82.69.10.202    82.69.1.37      MM_NO_STATE          0 ACTIVE

IPv6 Crypto ISAKMP SA

LaminatesFibre#



LaminatesFibre#show cryp ipsec sa

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 82.69.1.37

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (82.69.1.37/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (82.69.10.202/255.255.255.255/47/0)
   current_peer 82.69.10.202 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 5, #recv errors 0

     local crypto endpt.: 82.69.1.37, remote crypto endpt.: 82.69.10.202
     path mtu 1500, ip mtu 1500, ip mtu idb Dialer0
     current outbound spi: 0x0(0)
     PFS (Y/N): N, DH group: none

     inbound esp sas:

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:

     outbound ah sas:

     outbound pcp sas:
LaminatesFibre#

[jimwillsher]

ok, strange....I've re-keyed all the commands after a reload, and now it works! I've also had to add an allow all to my inbound ACL at both ends, allowing all from the "other side" public IP.

It seems to work, and looking at the output from the two sh cryp commands, it's encrpyting.

[Francesco Molino · Accepted solution]

Hi

Sorry for the late answer. You're talking about your acl-ext-in? When you're doing IPSEC encryption you'll need to add :

permit esp host x.x.x.x host x.x.x.x

permit udp host x.x.x.x host x.x.x.x eq isakmp

Thanks.

PS: Please don't forget to rate and mark as correct answer if this answered your question

[jimwillsher]

Brilliant! Initially I had

permit ip host remote.host.ip.address any

in acl-EXT-IN. But I've removed that and added the two rules you mention, and it seems to work :-) This is the output from the two sow crypto commands:

LaminatesFibre#show cryp isakm sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
82.69.1.37      82.69.10.202    QM_IDLE           2002 ACTIVE

IPv6 Crypto ISAKMP SA

LaminatesFibre#show cryp ipsec sa

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 82.69.1.37

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (82.69.1.37/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (82.69.10.202/255.255.255.255/47/0)
   current_peer 82.69.10.202 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 228, #pkts encrypt: 228, #pkts digest: 228
    #pkts decaps: 181, #pkts decrypt: 181, #pkts verify: 181
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 82.69.1.37, remote crypto endpt.: 82.69.10.202
     path mtu 1500, ip mtu 1500, ip mtu idb Dialer0
     current outbound spi: 0x91630BBD(2439187389)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0x71F38487(1911784583)
        transform: esp-3des esp-md5-hmac ,
        in use settings ={Transport, }
        conn id: 3, flow_id: Onboard VPN:3, sibling_flags 80000000, crypto map: Tunnel0-head-0
        sa timing: remaining key lifetime (k/sec): (4236741/54472)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x91630BBD(2439187389)
        transform: esp-3des esp-md5-hmac ,
        in use settings ={Transport, }
        conn id: 4, flow_id: Onboard VPN:4, sibling_flags 80000000, crypto map: Tunnel0-head-0
        sa timing: remaining key lifetime (k/sec): (4236742/54472)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     outbound ah sas:

     outbound pcp sas:
LaminatesFibre#

You've already been very kind to me with your assistance, but could I trouble you to cast your eye one final time over my configs? I've attached both and they are entire (except passwords). The parts I'm keen to get sanity-checked are the crypto stuff and also my access lists (acl-EXT-IN). For example, I have a DHCP server at both sites, but now that I'm no longer permitting all traffic, is it necessary for me to still be blocking DHCP?

Many thanks again for your time and help.

Jim

[Francesco Molino]

Hi

nice to hear that. Why blocking dhcp? It's for internal lan? If there isn't the same subnet on each part it's not needed but for security reason, youbcan continue blocking it.

thanks

PS: Please don't forget to rate and mark as correct answer if this solved your issue 

[jimwillsher]

Just my understanding - or lack thereof - of DHCP :-) I assumed that a device didn't know which subnet it was on, and sent the DHCP request out (broadcast), and I was worried that the DHCP server at the "other site" might reply. Am I mistaken?

Jim

[Francesco Molino]

The broadcast remains on the vlan except if you configured the ip dhcp-helper. However if subnets are different and also if you don't redirect dhcp broadcast on the other end, no chance to get flooded by dhcp request on the other end andno chance to get a reply. 

But again as I said, for security, it's better to control which traffic can pass through the tunnel and which one not. I will leave as it is to protect. 

Thanks 

PS: Please don't forget to rate and mark as correct answer if this solved your issue 

[jimwillsher]

Same vlan but different subnets, and no DHCP broadcast. So I should be safe.

Many thanks for your help, I couldn't have achieved it without your guidance. VERY much appreciated.

Jim (in Scotland)

[Francesco Molino]

You're very welcome 

Francesco