VPN site-to-site between Cisco 2801 Sonicwall TZ 215

[SCI_Mario]

Hi All,

I'm scratching my head on this one.

I am trying to set up a VPN tunnel between a Cisco 2801 (my end) and a Sonicwall TZ215 (remote end).  We seem to be getting through Phase 1 just fine, it keeps tanking on Phase 2.  There is no conflict between the local and remote network schemes, so I'd rather avoid NAT and just be able to hit the remote server by the private side address.

I have a border router (Cisco 2801) that I keep the VPNs on, and a Cisco PIX below that.  Traffic is flagged in my PIX to head out our fiber rather than the default route whenever it needs to go over a VPN, it's definitely taking the right path out.  On my PIX I do have this in my NAT0, though I've been doing all  tests from the Cisco 2801 hoping to just get the tunnel up first without overcomplicating things.

I've got 2 other VPNs running on this device, one using 3DES and one using AES, I just copied from the config for a very similar working VPN (changing the IPs and policy number). When using 3DES it seems to get through Phase 1 just fine, fails at Phase 2.  When using AES it fails at Phase 1.

Here is a snip of the config I've been using on the 2801:

****

interface FastEthernet0/1
ip address (public IP of router) 255.255.255.224
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
crypto map outside_map

crypto isakmp policy 40

 encr 3des
 hash md5
 authentication pre-share
 group 2

crypto isakmp key ######## address AAA.BBB.CCC.DDD (remote public address endpoint in Sonicwall)

crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto ipsec transform-set hryak ah-sha-hmac esp-aes 256
crypto ipsec transform-set ESP-AES256-MD5 esp-aes 256 esp-md5-hmac

crypto map outside_map 40 ipsec-isakmp
 set peer AAA.BBB.CCC.DDD (remote public ip address)
 set transform-set ESP-3DES-MD5
 match address 140

access-list 140 permit ip host (our global NAT) BBB.CCC.DDD.EEE 0.0.0.255 (remote private side network  /24)
access-list 140 permit tcp host (our global NAT)  BBB.CCC.DDD.EEE 0.0.0.255 (remote private side network /24)

What I'm seeing in my syslog is this:

2016-04-20 13:39:01 Local7.Debug 10.239.20.1 50: *Apr 20 20:02:48.056: IPSEC(ipsec_process_proposal): proxy identities not supported
2016-04-20 13:39:01 Local7.Debug 10.239.20.1 51: *Apr 20 20:02:48.056: ISAKMP:(4706): IPSec policy invalidated proposal with error 32
2016-04-20 13:39:01 Local7.Debug 10.239.20.1 52: *Apr 20 20:02:48.056: ISAKMP:(4706): phase 2 SA policy not acceptable! (local [ROUTER_PUBLIC_IP] remote [REMOTE_PUBLIC_IP])
2016-04-20 13:39:01 Local7.Debug 10.239.20.1 53: *Apr 20 20:02:48.060: ISAKMP:(4706):deleting node -660087920 error TRUE reason "QM rejected"
2016-04-20 13:39:16 Local7.Debug 10.239.20.1 54: *Apr 20 20:03:02.816: map_db_find_best did not find matching map
2016-04-20 13:39:16 Local7.Debug 10.239.20.1 55: *Apr 20 20:03:02.816: IPSEC(ipsec_process_proposal): proxy identities not supported
2016-04-20 13:39:16 Local7.Debug 10.239.20.1 56: *Apr 20 20:03:02.816: ISAKMP:(4706): IPSec policy invalidated proposal with error 32
2016-04-20 13:39:16 Local7.Debug 10.239.20.1 57: *Apr 20 20:03:02.816: ISAKMP:(4706): phase 2 SA policy not acceptable! (local [ROUTER_PUBLIC_IP] remote [REMOTE_PUBLIC_IP])
2016-04-20 13:39:16 Local7.Debug 10.239.20.1 58: *Apr 20 20:03:02.820: ISAKMP:(4706):deleting node -765628656 error TRUE reason "QM rejected"

Any suggestions of where I can look or some next steps?

Many thanks!

[Aditya Ganjoo · Accepted solution]

Hi,

As per the logs the issue seems to be with the crypto ACL (interesting traffic):

2016-04-20 13:39:01 Local7.Debug 10.239.20.1 50: *Apr 20 20:02:48.056: IPSEC(ipsec_process_proposal): proxy identities not supported

I see that you are using tcp permit in the crypto ACL ( acl 140) and you are also using IP on the first line so I do not see the relevance of tcp being used.

Could you verify the permitted ACL on SonicWall, are we matching it ?

Regards,

Aditya

Please rate helpful posts.

[SCI_Mario]

Hi Aditya,

Thank you so much for the quick response.  The TCP is because ultimately this is going to be for SQL replication to an offsite server, so TCP 1433 will be used (I just threw ip in there as that is what we had on a very similar setup on the same router).  Looking at it now I think I should have allowed ICMP if anything, just for testing at least.

On the Sonicwall end they are currently allowing all traffic through, but they specifically stated that they weren't seeing anything come through at all when I tried to ping.  Most of the errors we've been able to see on either side come from when they send traffic through.  

I agree it seems something with flagging the interesting traffic, but that's where I'm pretty stuck. I don't have a line specifically allowing ICMP traffic, but I don't have that in either of my working configs either.

I did remove my Nat0 statement from my PIX and am now seeming to get "interesting traffic", at least some sort of response from the router.  Seeing a lot of this now: 

04-25-2016 15:04:45 Local7.Debug 10.239.20.1 9054: *Apr 25 21:28:23.650: ISAKMP:(4726):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
04-25-2016 15:04:45 Local7.Debug 10.239.20.1 9053: *Apr 25 21:28:23.650: ISAKMP:(4726):Input = IKE_MESG_FROM_PEER, IKE_MESG_KEEP_ALIVE
04-25-2016 15:04:45 Local7.Debug 10.239.20.1 9052: *Apr 25 21:28:23.650: ISAKMP:(4726):purging node 209491311
04-25-2016 15:04:45 Local7.Debug 10.239.20.1 9051: *Apr 25 21:28:23.650: ISAKMP:(4726):Sending an IKE IPv4 Packet.
04-25-2016 15:04:44 Local7.Debug 10.239.20.1 9050: *Apr 25 21:28:23.650: ISAKMP:(4726): sending packet to [REMOTE_ROUTER_IP] my_port 500 peer_port 500 (I) QM_IDLE
04-25-2016 15:04:44 Local7.Debug 10.239.20.1 9049: *Apr 25 21:28:23.650: ISAKMP:(4726): seq. no 0x7AD0D642

[Aditya Ganjoo]

Hi Mario,

Ideally the ACL on both the devices should match.

Could you please share the entire debugs ?

Regards,

Aditya

[SCI_Mario]

Hi Aditya,

You were dead on with the traffic not being flagged as interesting.  Once I corrected that we started receiving an error on the SonicWall end that the "Peer's proposed network does not match VPN policy network".  I put my NAT0 statement back in the firewall to show my private side rather than the public NAT and we're connected.

Thanks!

[Aditya Ganjoo]

Hi Mario,

Glad to assist you. :)

Regards,

Aditya

[Pawan Raut]

I have noticed that you are using remote end Private Network. By default we always have default route towards ISP interface but you may have some aggregate summary route receiving from somewhere else so you should either check sh ip cef <IP address of customer> then output of this command should have Next hop as interface as FastEthernet0/1 if not then you have to put the static route towards ISP interface like consider remote network is 10.1.1.0/24

ip route 10.1.1.0 255.255.255.0 interface FastEthernet0/1