[solved] strange behaviour in ipsec site2site (was a p1 auto-negotiation issue)

[sw2090]

Hi,

I have the following setup here:

Side A:

 FGT 100E with 6.0.9

 lan subnet is xx.xx.xx.0/24

Side B:

 FGT 80C with 5.6.12 (latest available for 80C)

 lan subnet is yy.yy.yy.0/24

IPSec Site2Site between A and B is set up.

The Tunnel is up (green in monitor) and monitor does show there is traffic in both directions on this one.

now when I ping xx.xx.xx.10 from client yy.yy.yy.50 on Side B I get no response.

Flow Trace on Side B shows that the traffic goes out to side A over the IPsec as it should.

Flow Trace on Side A shows that the traffic coming from my client does reach side A and is routed on correctly

Flow Trace on Side A also shows me that there is traffic from xx.xx.xx.10 to my client and that it is routed over the Ipsec correctly.

However: Flow Trace on Side B with Filter saddr xx.xx.xx.10 and daddr yy.yy.yy.50 shows just nothing.

So looks to me as if the traffic coming back to my client on side B gets lost somewhere on the ipsec?

Did anyone here have this? Any clues?

Thnx in advance!

Sebastian

[sw2090]

hm diag debug gateway list lists two gateways on both sides (one for each direction on each side).

diag debug app ike -1 shows there is IKE SA Requests on both sides that are answered since it is matching proposals and gatway correctly. It also right afterwarts does NAT-T and NAT-D handshake successfull.

Right after this nothing more happens until either one SIDE retransmits or receives a RETRANSMIT query from the opposite side.

thus it stays stuck until after like 15mins.

DPD seems to work since I can see the tunnel goes down like 15sec after I entered exec reboot on the other side which seem sto meet the default DPD timeouts and retry count.

Maybe auto negation is the belzebub here too, since side A tries to re-autonegotiate the tunnel as soon as has gone down but opposite side is not yet there again. Could that cause dead SA's under some weird circumstances?

I will keep on searching...

[sw2090]

this is what diag vpn tunnel list reports on side A:

name=d_e1-messe_e1 ver=2 serial=37e xx.xx.xx.xx:4500-><remotegwip>:28919

bound_if=7 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/0

proxyid_num=1 child_num=0 refcnt=10 ilast=1 olast=1 ad=/0

stat: rxp=0 txp=0 rxb=0 txb=0

dpd: mode=on-idle on=1 idle=5000ms retry=3 count=0 seqno=15413

natt: mode=keepalive draft=0 interval=10 remote_port=28919

proxyid=t_d_e1-messe_e1 proto=0 sa=1 ref=2 serial=2 auto-negotiate

 src: 0:0.0.0.0/0.0.0.0:0

 dst: 0:0.0.0.0/0.0.0.0:0

 SA: ref=3 options=18227 type=00 soft=0 mtu=1438 expire=7414/0B replaywin=1024

 seqno=1 esn=0 replaywin_lastseq=00000000 itn=0

 life: type=01 bytes=0/0 timeout=14128/14400

 dec: spi=f1e85cd2 esp=3des key=24 73a5480aead7101386c92d4ebbb97da4eefbc1b320d80038

 ah=sha1 key=20 f5621e3f01ae26136ee0f78d74ff3f9630f002d8

 enc: spi=a7634197 esp=3des key=24 cb82ef81d9b0cc41f5dda109594966bc94882a84bf65a4c9

 ah=sha1 key=20 2b4793be6cfca7e1d6f1be77f54c66f00d8997d6

 dec:pkts/bytes=0/0, enc:pkts/bytes=0/0

 npu_flag=00 npu_rgwy=<ipofremotegw> npu_lgwy=xx.xx.xx.xx npu_selid=342 dec_npuid=0 enc_npuid=0

On Side B it looks equally (except from tunnel name and gw ips of course).

This is when the tunnel is up and running btw.

I see one more difference btw: Side A has dpd timeout 5000ms and retry count 3 while Side B has timeout 20000ms and retry count 3.

Done some more Debugging:

I can see in ike debug log on side a that dpd detects a link 5-10sec after I triggert a FGT reboot on side B. It shuts the tunnel down, deletes sa and flushes the tunnel. It also sends a snmp trap.

So DPD seems to work properly here.

[sw2090]

ok I seem to have found the corpus delicti now.

It is indeed caused by auto-negotiotiation. But not by auto-negotiation in p2, indeed it happens in p1.

And it is caused on Side A.

In fact DPD flushes the tunnel when it detects the link fail when I reboot FGT on side B.

Right after that p1 auto-negotiate tries to re-establish the tunnel which will fail because side B is not yet up again. This seems to create a dead connection on side A. Oncoming retries keep using this dead connection until it timeout.

I now disabled p1 auto-negotiation on Side A (I don't need side A to auto negotiate anyways). So Side B has to establlish the tunnel once it is back up again which is triggered by Side B p1 auto-negotiation. Since there is no connections for this tunnels on Side A yet then the tunnel fires up asap and works fine.

Up to now I didn't even know there is a auto-neg feature in p1. Articles I found keep referring to p2 only and gui once more don't show it at all :\

Alas thanx guys this is solved so far :)