I have a client that has 5 remote sites that connect back to the main office.
Remote sites now have new Cisco 891Ws. All but 1 of them receive addressing via DHCP (DSL).
Main site has the Sonicwall TZ190 Enhanced. 5 static addresses.
I have successfully configured the VPNs and gotten them connected back to the main site. The only way I knew how to accomplish this was to plug in the currently leased address in to the Sonicwall so that it would know which profile to use when establishing the SAs. Problem occurs when the address changes.
I have configured the Cisco side with 2 crypto map policies, 1 that matches the actual Sonicwall profile and a second that matches the WAN GroupVPN proposals so that when the address does change, they will still have 1 way connectivity back to the servers. But they lose the ability to print because something with the logic of the GroupVPN won't allow traffic originating from within the fire walled subnets to send traffic to clients connected via GroupVPN... I'm guessing it has to do with stateful packet inspection.
When I was setting this up in a lab, I was trying different things to get the Cisco to identify itself with something other than the IP address, but could never get it to work. Either the Cisco would fail to send the proper identifier or the Sonicwall was ignoring it and looking only at the incoming IP.
Any help would be greatly appreciated to try and get this resolved so I don't have to check in on the Sonicwall every morning.
Sample config below, all sites are the same.
Remote sites now have new Cisco 891Ws. All but 1 of them receive addressing via DHCP (DSL).
Main site has the Sonicwall TZ190 Enhanced. 5 static addresses.
I have successfully configured the VPNs and gotten them connected back to the main site. The only way I knew how to accomplish this was to plug in the currently leased address in to the Sonicwall so that it would know which profile to use when establishing the SAs. Problem occurs when the address changes.
I have configured the Cisco side with 2 crypto map policies, 1 that matches the actual Sonicwall profile and a second that matches the WAN GroupVPN proposals so that when the address does change, they will still have 1 way connectivity back to the servers. But they lose the ability to print because something with the logic of the GroupVPN won't allow traffic originating from within the fire walled subnets to send traffic to clients connected via GroupVPN... I'm guessing it has to do with stateful packet inspection.
When I was setting this up in a lab, I was trying different things to get the Cisco to identify itself with something other than the IP address, but could never get it to work. Either the Cisco would fail to send the proper identifier or the Sonicwall was ignoring it and looking only at the incoming IP.
Any help would be greatly appreciated to try and get this resolved so I don't have to check in on the Sonicwall every morning.
Sample config below, all sites are the same.
Code:
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
lifetime 28800
crypto isakmp key <removed for security> address <removed for security>
!
!
crypto ipsec transform-set PONCE_TRANSFORM esp-3des esp-sha-hmac
!
!
!
crypto map BARNESVPN 1 ipsec-isakmp
description Tunnel to Ponce
set peer <removed for security>
set security-association lifetime kilobytes disable
set security-association lifetime seconds 86400
set transform-set PONCE_TRANSFORM
set pfs group2
match address 150
crypto map BARNESVPN 2 ipsec-isakmp
description Backup Tunnel to Ponce with GroupVPN
set peer <removed for security>
set security-association lifetime kilobytes disable
set security-association lifetime seconds 28800
set transform-set PONCE_TRANSFORM
match address 150