"requesting service" cisco dynamic crypto maps

[Mikeal]

We have a few people setup to work remotely over cisco 5505's. I'm finding that anytime the VPN tunnel goes down, and then comes back up, the phones stop working. I've verified the problem is not related to DHCP leases. Other network functions over VPN work as expected. We are only having issue with the Shoretel phones(530s).

Can anyone shed some light on this?

[eazeaz]

Vpn

I assume that rebooting the phones after an outage fixes the problem?

It almost sounds like when the tunnel comes back up, it is not really passing UDP packets for a while, making the phones hang in "requesting service".

can you post your access lists, vpn, and nat configs?

[Mikeal]

Rebooting the phone does not solve the problem. I have to do a factory reset to get the phone back online. I've tried multiple phones as well.

access-list dmz_access_in extended permit object-group DM_INLINE_PROTOCOL_1 192.168.200.0 255.255.255.0 any log debugging
access-list outside_access_in extended permit object-group DM_INLINE_PROTOCOL_3 host xxx.xxx.xxx.xxx any
access-list inside_access_in extended permit object-group DM_INLINE_PROTOCOL_2 172.16.20.8 255.255.255.248 any log debugging
access-list outside_1_cryptomap extended permit ip 172.16.20.8 255.255.255.248 192.168.0.0 255.255.0.0
access-list nonat extended permit ip 172.16.20.8 255.255.255.248 192.168.0.0 255.255.0.0
access-list 101 extended permit udp any any range 5440 5445
access-list 101 extended permit udp any any eq 5004
access-list 101 extended permit udp any any eq 2427
access-list 101 extended permit udp any any eq 2727
access-list 101 extended permit tcp any any eq 5002
access-list 101 extended permit tcp any any eq 5004

nat (inside) 0 access-list nonat
nat (inside) 1 172.16.20.8 255.255.255.248
nat (inside) 1 0.0.0.0 0.0.0.0
nat (dmz) 1 0.0.0.0 0.0.0.0
access-group inside_access_in in interface inside
access-group outside_access_in in interface outside
access-group dmz_access_in in interface dmz

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto map outside_map 1 match address outside_1_cryptomap
crypto map outside_map 1 set peer xxx.xxx.xxx.xxx
crypto map outside_map 1 set transform-set ESP-3DES-SHA
crypto map outside_map interface outside
crypto isakmp identity address
crypto isakmp enable inside
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400

[Mikeal]

Forgot these:

object-group protocol DM_INLINE_PROTOCOL_1
protocol-object ip
protocol-object icmp
protocol-object udp
protocol-object tcp
object-group protocol DM_INLINE_PROTOCOL_2
protocol-object ip
protocol-object icmp
protocol-object udp
protocol-object tcp
object-group protocol DM_INLINE_PROTOCOL_3
protocol-object ip
protocol-object udp
protocol-object icmp
protocol-object tcp

[eazeaz]

phones

if you have to do a factory reset to bring the phone back online, then I wouldn't think that would be your tunnel. A simple reboot would bring the phone back if it was a tunnel delay issue (i would think anyway).

The phones are trying to connect to a shoretel switch that is across the WAN correct?

Where are the phones getting DHCP from? local or across the wan as well?

also, what version of shoretel are you on?

[Mikeal]

Switch is across VPN correct.
DHCP is being done locally by the 5505.

Shoretel 7.5

If i reboot the phone it will contact the ftp server, download the file, etc. Basically does everything i expect it to, but hangs with requesting service.

[Mikeal]

Also I worked from home myself last week to test this setup and had no issues. Only difference i can think of is I probably had a ping running across the VPN the entire time I was testing so I would assume the VPN tunnel never went down.

[Mikeal]

If I do everything in this order it makes the phone work(until the tunnel goes down again).

1) unplug the Shoretel 530 from the cisco 5505
2) power cycle the cisco 5505
3) do something to cause the VPN to connect on remote workstation
4) plug in the Shoretel 530

[Mikeal]

This is same issue I am having: http://www.shoretelforums.com/forums...erational.html

[Jason_C]

We have the same issue with our ASA's. We usually install some type of ping utility on a local computer that always running to keep the tunnel up.

To get a phone working again, something we have to do is delete the phone from the Director, and then reboot the phone. We are using 265 phones. I believe the ASA's are handling the DHCP.

[Miersk]

Just reclassify existing VPN flows, use the sysopt connection reclassify-vpn command in global configuration mode. When VPN tunnels come up, this command reclassifies existing VPN flows to make sure that flows that need encryption get torn down and recreated. This function is disabled by default.

[Mikeal]

SOLUTION (Cisco ASA):

To reclassify existing VPN flows, use the sysopt connection reclassify-vpn command in global configuration mode. When VPN tunnels come up, this command reclassifies existing VPN flows to make sure that flows that need encryption get torn down and recreated. This function is disabled by default.


On both ASA devices this needs to be turned on. You can check with:

show run all sysopt

Enable (in config mode) with:
sysopt connection reclassify-vpn

So far this has done the trick for us.