PIX 501 -> Sonicwall VPN 3030 VPN site-site tunnel problem

[sleste]

Hi,

having great difficulties in making these 2 hardwares establish a tunnel. The PIX is running 2 other tunnels already and is having no problems there. The remote-client has recently changed to a Sonicwall VPN 3030

and now the tunnel will not work. It seems to be stuck in phase 1 of tunnel negotiations. We have tried pretty much every aspect of changing all sorts of parameters, but to now avail.

The Sonicwall and PIX both seem to be experiencing some sort of timeouts during this phase, as from what we can see in the syslog of both devices.

The debug crypto ipsec on the PIX gives this result:

IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP

IPSEC(key_engine_delete_sas): delete all SAs shared with 194.154.208.162

IPSEC(key_engine): got a queue event...

IPSEC(spi_response): getting spi 0x2b0f50a0(722423968) for SA

from 194.154.208.162 to 193.213.24.110 for prot 3

IPSEC(key_engine): request timer fired: count = 1,

(identity) local= 193.213.24.110, remote= 194.154.208.162,

local_proxy= 192.168.200.0/255.255.255.0/0/0 (type=4),

remote_proxy= 172.28.0.7/255.255.255.255/0/0 (type=1)

IPSEC(key_engine): got a queue event...

IPSEC(spi_response): getting spi 0x74132d3(121713363) for SA

from 194.154.208.162 to 193.213.24.110 for prot 3

IPSEC(key_engine): request timer fired: count = 2,

(identity) local= 193.213.24.110, remote= 194.154.208.162,

local_proxy= 192.168.200.0/255.255.255.0/0/0 (type=4),

remote_proxy= 172.28.0.7/255.255.255.255/0/0 (type=1)

IPSEC(key_engine): got a queue event...

IPSEC(spi_response): getting spi 0x772f54de(1999590622) for SA

from 194.154.208.162 to 193.213.24.110 for prot 3

IPSEC(key_engine)

So...anyone out there having had similar problems etc.?

Steffen

[bigchoice75]

I don't see the keys being exchanged, are you using pre-share or rsa? Also, do you have ISAKMP, AH and ESP opened on both firewalls?

[sleste]

Hi,

and thanx for replying!

We are using pre-shared keys. ISAKMP, AH and ESP are enabled on the PIX. It should be the same on the other side, but I would have to check that on the remote-site Sonicwall. Have to ask the person in charge of that firewall.

I guess you might be right here. The firewall is timing out due to not having the right protocols enabled on both sides for completing, or in this case even starting, the authentication process.

Will have a further look on this issue.

Steffen