Netgear UTM50 – ProSECURE Unified Threat Management (UTM) Appliance ユーザーズマニュアル

[SRX5308] [IKE] Floating ports for NAT-T with peer 

116.66.200.178[28950]_

[SRX5308] [IKE] NAT-D payload does not match for 10.200.13.18[4500]_

[SRX5308] [IKE] NAT-D payload does not match for 

116.66.200.178[28950]_

[SRX5308] [IKE] NAT detected: Local is behind a NAT device. and also 

Peer is behind a NAT device_

[SRX5308] [IKE] ISAKMP-SA established for 

10.200.13.18[4500]-116.66.200.178[28950] with 

spi:14e465c525b13972:87ea734ec64e1c97_

[SRX5308] [IKE] Sending Informational Exchange: notify 

payload[INITIAL-CONTACT]_

[SRX5308] [IKE] Responding to new phase 2 negotiation: 

10.200.13.18[0]<=>116.66.200.178[0]_

[SRX5308] [IKE] Using IPsec SA configuration: 

192.168.30.0/24<->0.0.0.0/0 from srx_client.com_

[SRX5308] [IKE] No policy found, generating the policy : 

192.168.31.201/32[0] 192.168.30.0/24[0] proto=any dir=in_

[SRX5308] [IKE] Adjusting peer's encmode 61443(61443)->Tunnel(1)_

[SRX5308] [IKE] IPsec-SA established [UDP encap 28950->4500]: 

ESP/Tunnel 116.66.200.178->10.200.13.18 with spi=8414587(0x80657b)_

If a VPN tunnel is up but you cannot ping the remote endpoint, check the following:

Verify that the phase 2 settings are correct, in particular that the VPN Client address and 
the remote LAN address are correct. Normally the VPN Client address does not belong to 
the remote LAN subnet.

When a VPN tunnel is up, packets are sent with the Encapsulating Security Payload 
(ESP) protocol that could be blocked by a firewall. Verify that all devices between the 
VPN Client and the VPN router accept the ESP protocol.

Look at the VPN gateway logs. It is possible that the firewall of the VPN gateway dropped 
the packets.

Verify that your ISP supports ESP.

Use a network analysis software tool (such as the free Wireshark tool (visit 

) to analyze ICMP traffic on the LAN interface of the VPN router and 

on the LAN interface of the computer to see if encryption functions correctly.