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:
---x------#---------X
bdr fw core
where:
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 144.12.13.14 which is routed to the bdr via a /29, and then the bdr has a static for 144.12.13.14 to 192.168.0.1 on the fw, and the fw has a static for 144.12.13.14 to 192.168.0.5 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-start-marker
boot system flash:c1900-universalk9-mz.SPA.152-3.T1.bin
boot-end-marker
!
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
!
archive
log config
hidekeys
!
redundancy
!
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
drop
!
interface Loopback0
ip address ip.address.goes.here/32
no ip proxy-arp
!
interface Null0
no ip unreachables
!
interface Embedded-Service-Engine0/0
no ip address
shutdown
!
interface GigabitEthernet0/0
description stuff
ip address ip.address.goes.here/26
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 HSRP.ip.here.blah
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
shutdown
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
!
end
(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.
