Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

PIX to SonicWall VPN - not working, could anyone help ?

Hi all,

I am trying to set up a VPN tunnel from a PIX 506E (firmware 6.3(2)), to a SonicWall Pro firewall. It is not working at the moment. Phase 1 is ok but phase 2 is not, the VPN tunnel is not established and the security association is deleted after 1 minute or so. I have attached below the PIX config and a debug output of a VPN tunnel establishment attempt (slightly modified and cut for privacy reasons). The PIX already has two other VPNs configured that are working flawlessly.

I would be very grateful to anyone who would help me answering the following questions about this VPN setup :

1. In the debug output, what does the following mean ?

ISAKMP (0): retransmitting phase 2 (0/0)... mess_id 0xafc08a94

crypto_isakmp_process_block:src:remotevpnpeer, dest:vpnpix1-e0 spt:500 dpt:500

ISAKMP: error, msg not encrypted

2. In the config, i am not sure if the 3 static commands are necessary and how it could interact... what do you think ?

3. In which order do things happen in the PIX when traffic is issued from local network to remote network through the VPN ? is it NAT then access-list processing then VPN establishment ? or or access-list processing, then NAT then VPN ? or another possibility ?

4. How can i get this to work ?

Many thanks in advance for any help provided,

A.G.

########### NAMING #################################

vpnpix1 - is the local cisco PIX

remotevpnpeer - is the remote Sonicwall firewall

intranet - is the local network behind the PIX

remotevpnLAN - is the remote network behind the SonicWall

################ CONFIG #############################

PIX Version 6.3(2)

interface ethernet0 10full

interface ethernet1 10full

nameif ethernet0 outside security0

nameif ethernet1 inside security100

.../...

hostname vpnpix1

.../...

names

name A.B.C.D vpnpix1-e1

name X.Y.Z.T vpnpix1-e0

name E.F.G.H defaultgw

name 10.0.0.0 intranet

name 192.168.250.0 nat-intranet

name J.K.L.M internetgw

name 10.M.N.P server1

name 10.M.N.Q server2

name 10.M.N.R server3

name 192.168.252.0 remotevpnLAN

name 10.1.71.0 nat-remotevpnLAN

.../...

object-group network server-group

description servers used by remote LAN users conencted thru VPN tunnel

network-object host server1

network-object host server2

network-object host server3

.../...

access-list INBOUND permit tcp nat-remotevpnLAN 255.255.255.0 object-group server-group eq citrix-ica

.../...

access-list OUTBOUND permit ip intranet 255.0.0.0 nat-remotevpnLAN 255.255.255.0

access-list INTRANET-to-remotevpnLAN-VPN permit ip intranet 255.0.0.0 remotevpnLAN 255.255.255.0

access-list NONAT-to-remotevpnLAN permit ip intranet 255.0.0.0 nat-remotevpnLAN 255.255.255.0

.../...

ip address outside vpnpix1-e0 255.255.255.240

ip address inside vpnpix1-e1 255.255.252.0

.../...

global (outside) 1 192.168.250.1

nat (inside) 0 access-list NONAT-to-remotevpnLAN

nat (inside) 1 intranet 255.0.0.0 0 0

.../...

static (inside,outside) server1 server1 netmask 255.255.255.255 0 0

static (inside,outside) server2 server2 netmask 255.255.255.255 0 0

static (inside,outside) server3 server3 netmask 255.255.255.255 0 0

static (outside,inside) nat-remotevpnLAN remotevpnLAN netmask 255.255.255.0 0 0

.../...

access-group INBOUND in interface outside

access-group OUTBOUND in interface inside

route outside 0.0.0.0 0.0.0.0 internetgw 1

route inside intranet 255.0.0.0 defaultgw 1

.../...

sysopt connection permit-ipsec

.../...

crypto ipsec transform-set VPN-TS1 esp-3des esp-md5-hmac

.../...

crypto map BusinessPartners 30 ipsec-isakmp

crypto map BusinessPartners 30 match address INTRANET-to-remotevpnLAN-VPN

crypto map BusinessPartners 30 set peer remotevpnpeer

crypto map BusinessPartners 30 set transform-set VPN-TS1

crypto map BusinessPartners interface outside

isakmp enable outside

.../...

isakmp key ******** address remotevpnpeer netmask 255.255.255.255

isakmp identity address

isakmp policy 10 authentication pre-share

isakmp policy 10 encryption 3des

isakmp policy 10 hash md5

isakmp policy 10 group 2

isakmp policy 10 lifetime 28800

isakmp policy 20 authentication pre-share

isakmp policy 20 encryption 3des

isakmp policy 20 hash sha

isakmp policy 20 group 2

isakmp policy 20 lifetime 28800

isakmp policy 30 authentication pre-share

isakmp policy 30 encryption 3des

isakmp policy 30 hash md5

isakmp policy 30 group 1

isakmp policy 30 lifetime 28800

.../...

: end

################## DEBUG ############################

vpnpix1# debug crypto isakmp

vpnpix1#

ISAKMP (0): beginning Main Mode exchange

crypto_isakmp_process_block:src:remotevpnpeer, dest:vpnpix1-e0 spt:500 dpt:500

OAK_MM exchange

ISAKMP (0): processing SA payload. message ID = 0

ISAKMP (0): Checking ISAKMP transform 1 against priority 10 policy

ISAKMP: encryption 3DES-CBC

ISAKMP: hash MD5

ISAKMP: default group 2

ISAKMP: auth pre-share

ISAKMP: life type in seconds

ISAKMP: life duration (basic) of 28800

ISAKMP (0): atts are acceptable. Next payload is 0

ISAKMP (0): SA is doing pre-shared key authentication using id type ID_IPV4_ADDR

return status is IKMP_NO_ERROR

crypto_isakmp_process_block:src:remotevpnpeer, dest:vpnpix1-e0 spt:500 dpt:500

OAK_MM exchange

ISAKMP (0): processing KE payload. message ID = 0

ISAKMP (0): processing NONCE payload. message ID = 0

ISAKMP (0): processing vendor id payload

ISAKMP (0): ID payload

next-payload : 8

type : 1

protocol : 17

port : 500

length : 8

ISAKMP (0): Total payload length: 12

return status is IKMP_NO_ERROR

crypto_isakmp_process_block:src:remotevpnpeer, dest:vpnpix1-e0 spt:500 dpt:500

OAK_MM exchange

ISAKMP (0): processing ID payload. message ID = 0

ISAKMP (0): processing HASH payload. message ID = 0

ISAKMP (0): SA has been authenticated

ISAKMP (0): beginning Quick Mode exchange, M-ID of -1346336108:afc08a94

return status is IKMP_NO_ERROR

ISAKMP (0): sending INITIAL_CONTACT notify

ISAKMP (0): sending NOTIFY message 24578 protocol 1

VPN Peer: ISAKMP: Added new peer: ip:remotevpnpeer/500 Total VPN Peers:3

VPN Peer: ISAKMP: Peer ip:remotevpnpeer/500 Ref cnt incremented to:1 Total VPN Peers:3

crypto_isakmp_process_block:src:remotevpnpeer, dest:vpnpix1-e0 spt:500 dpt:500

ISAKMP (0): processing NOTIFY payload 14 protocol 1

spi 0, message ID = 476084314

return status is IKMP_NO_ERR_NO_TRANS

ISAKMP (0): retransmitting phase 2 (0/0)... mess_id 0xafc08a94

crypto_isakmp_process_block:src:remotevpnpeer, dest:vpnpix1-e0 spt:500 dpt:500

ISAKMP: error, msg not encrypted

ISAKMP (0): beginning Quick Mode exchange, M-ID of 1919346690:7266e802

crypto_isakmp_process_block:src:remotevpnpeer, dest:vpnpix1-e0 spt:500 dpt:500

ISAKMP: error, msg not encrypted

ISAKMP (0): retransmitting phase 2 (1/1)... mess_id 0xafc08a94

crypto_isakmp_process_block:src:remotevpnpeer, dest:vpnpix1-e0 spt:500 dpt:500

ISAKMP: error, msg not encrypted

ISAKMP (0): retransmitting phase 2 (0/2)... mess_id 0x7266e802

crypto_isakmp_process_block:src:remotevpnpeer, dest:vpnpix1-e0 spt:500 dpt:500

ISAKMP: error, msg not encrypted

ISAKMP (0): retransmitting phase 2 (2/3)... mess_id 0xafc08a94

crypto_isakmp_process_block:src:remotevpnpeer, dest:vpnpix1-e0 spt:500 dpt:500

ISAKMP: error, msg not encrypted

ISAKMP (0): retransmitting phase 2 (1/4)... mess_id 0x7266e802

crypto_isakmp_process_block:src:remotevpnpeer, dest:vpnpix1-e0 spt:500 dpt:500

ISAKMP: error, msg not encrypted

ISAKMP (0): beginning Quick Mode exchange, M-ID of -1475513565:a80d7323

ISAKMP (0): deleting SA: src vpnpix1-e0, dst remotevpnpeer

crypto_isakmp_process_block:src:remotevpnpeer, dest:vpnpix1-e0 spt:500 dpt:500

ISAKMP: drop msg for deleted sa

ISADB: reaper checking SA 0x10ff1ac, conn_id = 0 DELETE IT!

VPN Peer: ISAKMP: Peer ip:remotevpnpeer/500 Ref cnt decremented to:0 Total VPN Peers:3

VPN Peer: ISAKMP: Deleted peer: ip:remotevpnpeer/500 Total VPN peers:2

ISADB: reaper checking SA 0x1100984, conn_id = 0

ISADB: reaper checking SA 0x10fcddc, conn_id = 0

crypto_isakmp_process_block:src:remotevpnpeer, dest:vpnpix1-e0 spt:500 dpt:500

ISAKMP: sa not found for ike msg

#####################################################

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: PIX to SonicWall VPN - not working, could anyone help ?

Get rid of:

static (outside,inside) nat-remotevpnLAN remotevpnLAN netmask 255.255.255.0 0 0

You don't need it. Change:

access-list OUTBOUND permit ip intranet 255.0.0.0 nat-remotevpnLAN 255.255.255.0

access-list NONAT-to-remotevpnLAN permit ip intranet 255.0.0.0 nat-remotevpnLAN 255.255.255.0

to:

access-list OUTBOUND permit ip intranet 255.0.0.0 remotevpnLAN 255.255.255.0

access-list NONAT-to-remotevpnLAN permit ip intranet 255.0.0.0 remotevpnLAN 255.255.255.0

This will tell the PIX not to NAT the IPSec traffic. NAT happens BEFORE IPSec in the PIX, so if you nat the IPSec traffic it will never match your crypto access-list and will not be encrypted.

This, however, shouldn't stop the Phase 2 tunnel from being built, it would stop traffic flowing over the tunnel though, so you still have an issue somewhere. What I'm guessing is that the Sonicwall (SW) has a different crypto access-list defined, it needs to be the EXACT OPPOSITE of what is configured on the PIX. In other words, the SW needs to be encrypting traffic from "remotevpnLAN/24" to "intranet/8", make sure the subnet masks ar ethe same also.

To answer your questions:

1. This just means the PIX didn't receive a response and is retransmitting the last ISAKMP packet. The process_block just means the PIX has dropped a packet that needed to be encrypted because the IPSec tunnel wasn't built. If you get the tunnel built, these messages will go away.

2. The first 3 statics don't seem to be related to the IPSec tunnel, if they're simply for acces to an inside server then they won't be affecting this VPN tunnel. The last one should be removed as I've already stated.

3. For traffic initiated from the inside of the PIX, the order is inbound ACL processing, then NAT, the IPSec. This is why your OUTBOUND ACL has to allow the traffic in first, then your NAT 0 statement denies it from being NAT'd, then the crypto function matches the traffic and encrypts it.

4. Do what I've said above :-)

If you still have no luck, re-run the debugs, but initiate traffic from behind the Sonicwall, this way the Sonicwall will try and build the tunnel and you'll get more informative debugs on the PIX. Primarily we'll see what traffic pattern the SonicWall is configured to encrypt (you don't see that if the PIX initiates the tunnel).

2 REPLIES
Cisco Employee

Re: PIX to SonicWall VPN - not working, could anyone help ?

Get rid of:

static (outside,inside) nat-remotevpnLAN remotevpnLAN netmask 255.255.255.0 0 0

You don't need it. Change:

access-list OUTBOUND permit ip intranet 255.0.0.0 nat-remotevpnLAN 255.255.255.0

access-list NONAT-to-remotevpnLAN permit ip intranet 255.0.0.0 nat-remotevpnLAN 255.255.255.0

to:

access-list OUTBOUND permit ip intranet 255.0.0.0 remotevpnLAN 255.255.255.0

access-list NONAT-to-remotevpnLAN permit ip intranet 255.0.0.0 remotevpnLAN 255.255.255.0

This will tell the PIX not to NAT the IPSec traffic. NAT happens BEFORE IPSec in the PIX, so if you nat the IPSec traffic it will never match your crypto access-list and will not be encrypted.

This, however, shouldn't stop the Phase 2 tunnel from being built, it would stop traffic flowing over the tunnel though, so you still have an issue somewhere. What I'm guessing is that the Sonicwall (SW) has a different crypto access-list defined, it needs to be the EXACT OPPOSITE of what is configured on the PIX. In other words, the SW needs to be encrypting traffic from "remotevpnLAN/24" to "intranet/8", make sure the subnet masks ar ethe same also.

To answer your questions:

1. This just means the PIX didn't receive a response and is retransmitting the last ISAKMP packet. The process_block just means the PIX has dropped a packet that needed to be encrypted because the IPSec tunnel wasn't built. If you get the tunnel built, these messages will go away.

2. The first 3 statics don't seem to be related to the IPSec tunnel, if they're simply for acces to an inside server then they won't be affecting this VPN tunnel. The last one should be removed as I've already stated.

3. For traffic initiated from the inside of the PIX, the order is inbound ACL processing, then NAT, the IPSec. This is why your OUTBOUND ACL has to allow the traffic in first, then your NAT 0 statement denies it from being NAT'd, then the crypto function matches the traffic and encrypts it.

4. Do what I've said above :-)

If you still have no luck, re-run the debugs, but initiate traffic from behind the Sonicwall, this way the Sonicwall will try and build the tunnel and you'll get more informative debugs on the PIX. Primarily we'll see what traffic pattern the SonicWall is configured to encrypt (you don't see that if the PIX initiates the tunnel).

New Member

Re: PIX to SonicWall VPN - not working, could anyone help ?

Hi,

Actually I did need to NAT incoming source addresses from remoteLAN so i have left it like :

access-list NONAT-to-remotevpnLAN permit ip intranet 255.0.0.0 nat-remotevpnLAN 255.255.255.0

and

access-list OUTBOUND permit ip intranet 255.0.0.0 nat-remotevpnLAN 255.255.255.0

The helpful tip was to re-run the debugs, but initiate traffic from behind the Sonicwall... I got some interesting outputs that helped solving... The issue was that our PIX firewall was expecting traffic to come from RemoteLAN as from a translated IP range, which is something the SonicWall device seems not capable of (seems it can only send traffic with real source addresses or hide it behind its public interface's IP address). So we ended up in using their real source addresses and do NAT of those in the PIX... I modified my crypto ACL and NAT statements accordingly (modified the static statement) and now the VPN mounts when initiated from whichever side :-)

I was right from the begginning to be suspicious at the crypto ACL, but could only be sure with the other side initiating and giving me debug material...

Thanks gfullage as your advice somehow help solving my issue.

517
Views
0
Helpful
2
Replies
CreatePlease login to create content