No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

When Ipesc establish for a while,it will disconnect automatically,but it cannot connect automatically for long time

Publication Date:  2012-09-21 Views:  2 Downloads:  0
Issue Description
The network of some office as follows:

When the tunnel establish for a while,it will disconnect automatically, the traffic cannot trigger the tunnel establishing,we must cancel the policy of interface then it can establish tunnel by appling the policy again.
Alarm Information
None.
Handling Process
1、 If the tunnel can be establishe ,the negotiation parameter is normal.We can doubt that the aging time is out but the counterparty SA don’t delete it in time and the tunnel cannot be established.When we execute RESET IKE SA and RESET IPSEC SA on the equipment ,we can find the IPSEC SA outbound direction cannot be deleted,display as follows :
[inbound SAs:invalid]
[outbound ESP SAs]
spi: 209274653 (0xc79471d)
vpn: 0 said: 19 cpuid: 0x0000
proposal: ESP-ENCRYPT-DES ESP-AUTH-MD5
sa remaining key duration (bytes/sec): 1887436800/0
max sent sequence-number: 1
udp encapsulation used for nat traversal: N
[inbound SAs:invalid]
[outbound ESP SAs]
spi: 5697061 (0x56ee25)
vpn: 0 said: 21 cpuid: 0x0000
proposal: ESP-ENCRYPT-DES ESP-AUTH-MD5
sa remaining key duration (bytes/sec): 1887410043/0
max sent sequence-number: 428
udp encapsulation used for nat traversal: N
[inbound SAs:invalid]
checking session as follows:
udp VPN:public --> public
Zone: untrust--> local TTL: 00:02:00 Left: 00:01:46
Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00
<--packets:4 bytes:384 -->packets:6 bytes:968
3.3.3.3:500-->1.1.1.1:500
When the SA aging time is out,it need negotiate again and the tunnel disconnects .Checking the session ,we can find IP 3.3.3.3 launches negotiation session to IP 1.1.1.1(USG2100),but the USG2100 point the address which is 2.2.2.2,it is failed to negotiate and cannot establish tunnel.
There are two possibilities of this problem:
1、 Another equipment launch IPSEC negotiation to USG2100
2、 There is a NAT equipment at the USG5300 front line makes IP 2.2.2.2 transform to 3.3.3.3.Telnet 1.1.1.1 on the USG5300,then we can find the USG5300 front line has done NAT when we look over the session of USG2100.
The USG2100 IKE SA aging time is out ,it will notice 2.2.2.2(USG5300),but the source of answer data is 3.3.3.3.The equipment conside counterparty has no answer and the outbound directional IPSEC SA cannot be deleted.If USG5300 launch proactively ,USG2100 can establish tunnel normally by changing to template form and testing normally ,but after watching for a while the problem come back ,it cannot establish normally after disconnecting.
Checking the negotiation session(USG5300):
udp VPN:public --> public ---negotiation subsequent packet,port is 4500,the IP address is 4.4.4.4 after NAT
Zone: untrust--> local TTL: 00:02:00 Left: 00:01:53
Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00
<--packets:0 bytes:0 -->packets:16 bytes:3005
4.4.4.4:4500-->1.1.1.1:4500

udp VPN:public --> public --- negotiation subsequent packet,port is 500,the IP address is 3.3.3.3 after NAT
Zone: untrust--> local TTL: 00:02:00 Left: 00:01:46
Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00
<--packets:1 bytes:296 -->packets:1 bytes:296
3.3.3.3:500-->1.1.1.1:500
checking USG2100 session:
udp VPN:public --> public
Zone: local--> untrust TTL: 00:02:00 Left: 00:01:45
Interface: Ethernet0/0/0 NextHop: 1.1.1.2 MAC: 00-0f-e2-1c-ec-ec
<--packets:0 bytes:0 -->packets:11 bytes:1828
1.1.1.1:4500-->3.3.3.3:4500 –all the negotiation data comeback to the address 3.3.3.3
USG5300 find the tunnel negotiation by 3.3.3.3, there is NAT equipment in center by probe.Using the 4500 port to negotiate,and the source address is 4.4.4.4.Checking the USG2100 session ,all the answer data of address 1.1.1.1 return to 3.3.3.3 .The send address 4.4.4. cannot incept the answer data message ,it will lead to that the negotiation cannot be successful .This problem only can be solved by modifing NAT policy .This problem cannot be exist in our products because our products have done NAT transform the same IP address for the same source IP address
Root Cause
There is a equipment which at the USG5120 front line has done the NAT translation to USG5120 , it leads to USG2160 cannot trigger proactively and the tunnel can only be established by USG5120 triggering proactively.
Suggestions
We should observe the negotiation session when we meet the problem of no IPSEC VPN negotiation parameter.

END