Showing results for 
Search instead for 
Did you mean: 
Join Customer Connection to register!
Drew T

Replacing 1841 12.4 advsec with 1941 15.2M SEC/K9 causes issues

Curly one for the experts around here:)

I decided recently to switch out our border router (1841 12.4 advsecurity) with a shiny new 1941 (15.2 SEC/K9) as the CPU upgrade was needed.

In doing so, I seem to have introduced some strange issues.

The core below acts as a VPN end point to various other remote offices we have, all of which have a similar network design at each end (and all entirely managed by me). All of these are still running 1841's with 12.4 advsecurity on them as well. These are all GRE tunnels with ipsec procection on them (not crypto maps).

Before the change out, the network looked like this:


bdr       fw         core


bdr is a 1841 with advsecurity 12.4 on it

fw is a linux fw with iptables

core is an 1841 with advsecurity 12.4 on it.

If I swap out the bdr with a 1941 running SEC/K9 on 15.1 (or 15.2)T, I see issues.

The IPSEC establishment from the core to the remote site starts, and I see the phase I packet on the remote. The remote sees it, and replies, but the bdr is either not seeing it, or is dropping it entirely.

I've gone through caveats and all, and not seen anything in 15.1/2 that may cause this (and trying to search for anything anywhere is near impossible.

FWIW, there are statics everywhere to ensure that the path from internet to core and vice versa, take this exact path (so there's symmetric routing).

If I change nothing and put the 1841 back in, I see things come straight back.

The GRE tunnels are using RFC1918 /30's for the tunnels themselves, but public IP for the end points obviously, via a loopback for each tunnel on the core. On the bdr, there's a static route for the public IP towards the core, via the fw (and the fw has a static to an RFC1918 on the core). The public IP is a loopback on the core (so say Loopback10 on core is which is routed to the bdr via a /29, and then the bdr has a static for to on the fw, and the fw has a static for to on the core, where the loopback is). This is how all my tunnels are setup, and they all worked, until the swap-out.

Here's the relevent parts of the 1941 config:

version 15.2

service nagle

no service pad

service tcp-keepalives-in

service tcp-keepalives-out

service timestamps debug datetime msec show-timezone

service timestamps log datetime msec show-timezone

service password-encryption

no service dhcp


hostname routername



boot system flash:c1900-universalk9-mz.SPA.152-3.T1.bin



logging buffered 16000

logging console critical

enable secret <removed>


ipv6 spd queue min-threshold 62

ipv6 spd queue max-threshold 63

no ipv6 cef

no ip source-route

ip auth-proxy max-login-attempts 5

ip admission max-login-attempts 5


no ip bootp server

ip inspect log drop-pkt

ip inspect one-minute low 2000

ip inspect one-minute high 2500

ip inspect tcp idle-time 7500

ip inspect name STATEFUL h323

ip inspect name STATEFUL realaudio

ip inspect name STATEFUL rtsp

ip inspect name STATEFUL icmp

ip inspect name STATEFUL sip

ip inspect name STATEFUL udp

ip inspect name STATEFUL tcp

ip ips notify SDEE

ip ips name IDS-WATCH

ip cef

ip cef accounting per-prefix non-recursive prefix-length


multilink bundle-name authenticated

parameter-map type inspect global

log dropped-packets enable


vpdn enable


license udi pid CISCO1941/K9 sn <removed>

license boot module c1900 technology-package securityk9



log config





ip tcp selective-ack

ip ssh time-out 60

ip ssh authentication-retries 2


class-map match-any torrent


policy-map no-torrent

class torrent



interface Loopback0

ip address

no ip proxy-arp


interface Null0

no ip unreachables


interface Embedded-Service-Engine0/0

no ip address



interface GigabitEthernet0/0

description stuff

ip address

ip access-group stuff-in in

no ip redirects

no ip proxy-arp

ip nbar protocol-discovery

ip nat inside

no ip virtual-reassembly in

standby 1

standby 1 priority 105

standby 1 preempt

standby 1 authentication keyhere

ip tcp adjust-mss 1452

ip policy route-map stuff-route-map

load-interval 30

duplex auto

speed auto

no cdp enable

service-policy input no-torrent

service-policy output no-torrent


interface GigabitEthernet0/1

no ip address


duplex auto

speed auto


interface ATM0/0/0

no ip address

load-interval 30

no atm ilmi-keepalive

snmp ifindex persist

hold-queue 224 in

interface ATM0/0/0.835 point-to-point

pvc 8/35

  encapsulation aal5snap

  pppoe-client dial-pool-number 1


interface Dialer1

mtu 1452

ip address negotiated

ip access-group Internet-in in

ip access-group Internet-out out

no ip unreachables

ip accounting output-packets

ip accounting access-violations

ip nbar protocol-discovery

ip flow ingress

ip nat outside

ip inspect STATEFUL out

ip virtual-reassembly in

encapsulation ppp

ip policy route-map nachi-worm

load-interval 30

dialer pool 1

ppp authentication pap callin

ppp chap refuse

<auth string here>

ppp ipcp route default

no cdp enable

service-policy input no-torrent

service-policy output no-torrent


ip forward-protocol nd


no cdp run



(this is copied and pasted directly from the 1841, with the exception of the 15.2 line obviously, and all lines were applied without error).

Everything else works fine (NAT, route-maps etc), it's just these IPSEC/isakmp tunnels that are not playing ball.

Anyone seen anything like this before? It's definitely not an ARP issue (all arps were cleared) and ICMP appears to work fine (ie, I can ping the remote tunnel's public IP endpoint from the core using the loopback for that tunnel as the source). I am suspecting it's something strange with the stateful firewall config, but I did try and apply ipsec and isakmp-msft to the ip inspect list, with no success.

Drew T

FYI of anyone interested, I managed to fix this. For some reason, moving from 12.4 to 15.2 a route-map setting was deemed to not be happy (ie, didn't work). Instead of 'set ip next-hop x.x.x.x' I changed it to 'set interface Dialer1' and it worked. Go figure!