We have a site to site vpn between a
ASA5510 and Forefront TMG2010
Phase I
AES256 SHA1
DH Group 2
Phase II
AES256 SHA1
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
Local Gateway 80.x.x.x.x
Remote Gateway 200.x.x.x
The VPN encrypts two networks on our side, and one network on the client side
10.1.1.0/24 local remote 192.168.1.0/24
10.2.1.0/24 local
The cisco config is standard, the same as our other 30 site-to-site vpns.
On the TMG
I believe it uses the network defined as internal, shich contains the 192.168.1.0/24 network
the remote networks and the gateway peer are also defined in the wizrd.
The correct sh crypto ipsec sa peer 200.x.x.x output is:
peer address: 200.x.x.x
Crypto map tag: VPNMAP, seq num: 50, local addr: 80.x.x.x
access-list TMGCLIENT permit ip 10.1.1.0 255.255.255.0 192.168.1.0 255.255.255.0
local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0
current_peer: 200.x.x.x
#pkts encaps: 774, #pkts encrypt: 774, #pkts digest: 774
#pkts decaps: 547, #pkts decrypt: 547, #pkts verify: 547
Crypto map tag: VPNMAP, seq num: 50, local addr: 80.x.x.x
access-list TMGCLIENT permit ip 10.1.1.0 255.255.255.0 192.168.1.0 255.255.255.0
local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
current_peer: 200.x.x.x
#pkts encaps: 397, #pkts encrypt: 397, #pkts digest: 397
#pkts decaps: 383, #pkts decrypt: 383, #pkts verify: 383
The problem we have is after 8 hours the phase 2 tries to rekey, and the renegotiation does not match what it did the first time. The ASA sees it picked up by the outside_dyn_map crypto map, as for some reason it is not matched by my defined VPNMAP crypto map which is what it needs to work properly.
peer address: 200.x.x.x
Crypto map tag: outside_dyn_map, seq num: 50, local addr: 80.x.x.x
access-list ODAM permit ip 10.1.1.0 255.255.255.0 192.168.1.0 255.255.255.0
local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
current_peer: 200.x.x.x
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
Crypto map tag: outside_dyn_map, seq num: 50, local addr: 80.x.x.x
access-list ODAM permit ip 10.2.1.0 255.255.255.0 192.168.1.0 255.255.255.0
local ident (addr/mask/prot/port): (10.2.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
current_peer: 200.x.x.x
#pkts encaps: 189968, #pkts encrypt: 189971, #pkts digest: 189971
#pkts decaps: 347420, #pkts decrypt: 347420, #pkts verify: 347420
AND a weird third one, with the remote gateway address appearing in the remote ident!
Crypto map tag: outside_dyn_map, seq num: 10, local addr: 80.x.x.x
local ident (addr/mask/prot/port): (10.2.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (200.x.x.x/255.255.255.255/0/0)
current_peer: 200.x.x.x
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 17, #pkts decrypt: 17, #pkts verify: 17
Does anyone have any experience with TMG VPN's to see why it is sending its peer address as the remote ident?
I have looked at numerous docs, videos etc and all of them have the remote peer gateway listed in the Addressess tab of the VPN poperties page.
Also when running
sh asp table vpn-context detail
I see that this VPN is the only one (of our 40 or so) with an external address:
VPN CTX = 0x07C0F12C
Peer IP = 200.x.x.x
Pointer = 0xAB906A48
State = UP
Flags = DECR+ESP
SA = 0x70D77855
SPI = 0xD813404D
Group = 1
Pkts = 116
Bad Pkts = 0
Bad SPI = 0
Spoof = 0
Bad Crypto = 0
Rekey Pkt = 0
Rekey Call = 0
VPN CTX = 0x07C10544
Peer IP = 200.x.x.x
Pointer = 0xAC7E09D0
State = UP
Flags = ENCR+ESP
SA = 0x70D6B2F7
SPI = 0x80FCFDD5
Group = 0
Pkts = 0
Bad Pkts = 0
Bad SPI = 0
Spoof = 0
Bad Crypto = 0
Rekey Pkt = 0
Rekey Call = 0
could we be hitting this bug? we are running 8.2(1)
Symptom:
When testing 100 site to site vpn connections on an ASA running 8.2.1 one or two tunnels would not encrypt traffic.
The connections were established and dropped multiple times before seeing this issue.
Conditions:
"sho asp table vpn-context detail " shows duplicate crypto table entries.
Two current and one left over from previous connection.
This creates the problem of the traffic not being encrypted.
Workaround:
1. Reload ASA.or
2. Upgrade to get the fix for both CSCtb53186 and CSCtd36473. CSCtd36473 is a defect with a very similar symptom but different root cause.
This bug is resolved on version 8.2(4)
