AR18-30E cannot interoperate using IPSEC Tunnel (3DES + SHA � ISAKMP ) with C Router when there is a PIX between them.
Customer has a Network with many C routers (1700 Series). For topology details check the attachment “IPSec.ppt” .
Huawei AR1830E Software Version: Version 3.40, Feature 0117
C 1700 Software Version: Version 12.2(7r)XM2, RELEASE SOFTWARE (fc1)
PIX515E Software Version: PIX Security Appliance Software Version 7.2(1)
When we have the PIX at Network, the IPSec Tunnel is not established. We can observe that only IPSec phase 1 is completed, but the phase 2 is not completed and the Tunnel is not UP. Some errors like unexpected payload VENDOR is seen on debug logs.
<Quidway> disp ike sa
total phase-1 SAs: 0
connection-id peer flag phase doi
9 <unnamed> NONE 2 IPSEC
1) Check if the Shared Key of Huawei Router (IPsec configuration) and tunnel-group DefaultL2LGroup ipsec-attributes are the same.
2) Check if the Shared Key of Huawei Router (IPSec Configuration) and tunnel-group DefaultRAGroup ipsec-attributes are DIFFERENT.
3) Check the results again.
AR18-30E not established the IPSec Tunnel due to some configurations on PIX 515E ( C equipment), then firewall reject the IPSec tunnel and the messages of errors can be seeing at debug analyses.
<Quidway>debug ike error
*0.28228184 Quidway IKE/8/DEBUG:exchange run: unexpected payload VENDOR
*0.28229602 Quidway IKE/8/DEBUG:exchange run: unexpected payload VENDOR
*0.28230159 Quidway IKE/8/DEBUG:exchange run: unexpected payload VENDOR
*0.28230640 Quidway IKE/8/DEBUG:exchange_finalize: lack of IKE tunnel for the SA of phase 2.
The main point is, Huawei Router cannot authenticate into PIX515E by using the PIX policy DefaultRAGroup, Huawei cannot act as Remote Access device.
So the pre-shared key of Huawei Policy configuration and DefaultRAGroup PIX Configuration should be different, so the PIX will negotiate with Huawei Router using the DefaultL2LGroup Policy. Then the shared-key of Huawei Router and shared key of DefaultL2LGroup Policy PIX must be the same.