|
site A(A)------IPsec tunnel -----site B(B)
1) Running the debugs shows the following output:
# di de console timestamp en
# di de app ike -1
# di de en
2022-09-22 13:05:12.378979 ike 0:A:411492: sent IKE msg (P1_RETRANSMIT): 192.168.110.12:500->172.16.111.12:500 len=192, id=9432dc4305ddcb99/6f78bfef400060ec
2022-09-22 13:05:12.390287 ike 0: comes 172.16.111.12:500->192.168.110.12:500,ifindex=10....
initially was getting the error request is in the queue and now getting the error of ike shrank , the sniffer on the remote shows
22-09-22 13:03:08.312637 port2 out 192.168.110.12.500 -> 172.16.111.12.500: udp 192
2022-09-22 13:03:18.186185 port2 out 192.168.110.12.500 -> 172.16.111.12.500: udp 572
2022-09-22 13:03:18.301339 port2 in 172.16.111.12.500 -> 192.168.110.12.500: udp 572
2022-09-22 13:03:18.301391 port2 out 192.168.110.12.500 -> 172.16.111.12.500: udp 192
2022-09-22 13:03:21.188081 port2 out 192.168.110.12.500 -> 172.16.111.12.500: udp 572
local site shows
1D5478871D84E4CE000000000000000001100200000000000000023C0D000154000000010000000100000148010100080300002801010000800B0001000C00040001518080010007800E008080030001800200048004000E0300002802010000800B0001000C00040001518080010007800E00808003000180020004800400050300002803010000800B0001000C00040001518080010007800E010080030001800200048004000E0300002804010000800B0001000C00040001518080010007800E01008003000180020004800400050300002805010000800B0001000C00040001518080010007800E008080030001800200028004000E0300002806010000800B0001000C00040001518080010007800E00808003000180020002800400050300002807010000800B0001000C00040001518080010007800E010080030001800200028004000E0000002808010000800B0001000C00040001518080010007800E01008003000180020002800400050D0000144A131C81070358455C5728F20E95452F0D0000147D9419A65310CA6F2C179D9215529D560D000014CD60464335DF21F87CFDB2FC68B6A4480D00001490CB80913EBB696E086381B5EC427B1F0D00001416F6CA16E4A4066D83821A0F0AEAA8620D0000144485152D18B6BBCD0BE8A8469579DDCC0D000014AFCAD71368A1F1C96B8696FC775701000D0000144048B7D56EBCE88525E7DE7F00D6C2D30D0000184048B7D56EBCE88525E7DE7F00D6C2D3C0000000000000148299031757A36082C6A621DE00000000
2022-09-22 13:10:53.519475 ike 0:B_1:2053: sent IKE msg (P1_RETRANSMIT): 172.16.111.12:500->192.168.110.12:500, len=572, id=1d5478871d84e4ce/0000000000000000
2022-09-22 13:11:02.499245 ike 0:B_1:2053: negotiation timeout, deleting
2022-09-22 13:11:02.499447 ike 0:B_1: connection expiring due to phase1 down
2022-09-22 13:11:02.499491 ike 0:B_1: deleting
2022-09-22 13:11:02.499529 ike 0:B_1: deleted
2022-09-22 13:11:02.499560 ike 0:B_1: schedule auto-negotiate
2022-09-22 13:11:03.509281 ike 0:B_1:2060: initiator: main mode is sending 1st message...
2022-09-22 13:11:03.509419 ike 0:B_1:2060: cookie 20bcfa1cd37b39a1/0000000000000000
Line 132: 2022-09-22 12:34:40.068828 ike 0:B:1597: negotiation timeout, deleting
From the ike daemon’s perspective there was no response from the wan1 of site A.
The sniffer on both sides shows the port 2 and wan1 were being used on site A and site B respectively:
B_400E (root) # di sniffer packet any 'host 172.16.111.12 and port 500' 4 0 l
interfaces=[any]
filters=[host 172.16.111.12 and port 500]
2022-09-22 12:36:01.297666 port2 out 192.168.110.12.500 -> 172.16.111.12.500: udp 192
2022-09-22 12:36:01.307319 port2 in 172.16.111.12.500 -> 192.168.110.12.500: udp 572
2022-09-22 12:36:01.307340 port2 out 192.168.110.12.500 -> 172.16.111.12.500: udp 192
2022-09-22 12:36:10.347270 port2 in 172.16.111.12.500 -> 192.168.110.12.500: udp 572
2022-09-22 12:36:10.347326 port2 out 192.168.110.12.500 -> 172.16.111.12.500: udp 192
A_60E # di sniffer packet any 'host 192.168.110.12 and port 500' 4 0 l
interfaces=[any]
filters=[host 192.168.110.12 and port 500]
2022-09-22 13:24:29.548993 wan1 in 192.168.110.12.500 -> 172.16.111.12.500: udp 572
2022-09-22 13:24:30.054244 wan1 out 172.16.111.12.500 -> 192.168.110.12.500: udp 572
2022-09-22 13:24:30.139612 wan1 in 192.168.110.12.500 -> 172.16.111.12.500: udp 192
2022-09-22 13:24:32.548748 wan1 in 192.168.110.12.500 -> 172.16.111.12.500: udp 572
The MAC address of Site A was E8:1C:BA:03:B7:72:
But the PCAP showed the MAC being used was E8:1C:Ba:03:B6:Aa:
Thus the endpoint was forced to drop because of which the ike response packet was never sent to the Ike daemon and the tunnel was never up and working.
As the device was replaced and cables were plugged into an already running modem the old arp-entry was stuck in the arp-cache due to which the tunnel was not working.
So, after rebooting the modem the tunnels were up and traffic was passing.
|
