[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 it looks like as if i solved it myself.

first I found that NAT-T was not enabled on one side but enabled on the opposite side. 

So I enabled it and brought the tunnel down on this side to have it re-establish itself automagically which it did.

The behaviour was still the same...

Then I found some hint on Mike's Fortinet Guru Page. The was a paragraph about restarting ike and clearing old gateways.

So I did 

diag vpn ike restart

diag vpn ike gateway clear

and after those:

diag vpn ike status

this showed me that one ipsec tunnel was up again. There is two others but those have different policies and routes etc so they don't affect this one. Those are not up yet because I still have to create their remote end ;)

after this I tried pinging again and...magically...it works now....

[sw2090]

hm it works from B to A now. Even remote desktop works from Client on Side B to Server on Side A.

But if I try to ping from A to B my traffic gets dropped (denied by forward policy check (Policy #0) even though there devinitely is a matching policy in place (it showed me it matched it in flow debug before). 

It finds the correct route but seems not to match my policy anymore...

[emnoc]

You need to double check policy and possible  "diag sniffer packet <tunnel_name>"

BTW NAT-T is negotiated at phase1 and HAS NOTHING to do with phase2 which are SA ....i.e layer3 proxy-ids

I would double check policy , routes and ensure NAT is off if not required.

Ken Felix

[sw2090]

never said NAT-T had to do something with phase 2. p2 was up fine all the time accoarding to the output of diag vpn ike status...

I just noticed it wasn't turned on on Side B but should be since this is behind a LTE Router so I turned it on...

[sw2090]

correction again :)

That it worked in one direction only was due to the client on side A which i used to ping side B.

This client is in two subnets and so has two default routes and their metric struck me this time ;)

On that client that is wanted behaviour ;)

I tried on one that is only in xx.xx.xx.0/24 and it worked from there as it should ;)

I consider this last one to be a layer-8-fail :D

[sw2090]

Right,

new problem now:

ipsec is up and working fine so far.

Now if I reboot remote end (side B) tunnel goes down (of course)..ok so far :)

remote end comes up again but tunnel is still down and takes ages until it comes up again.

Once it is back up again it works fine again.

When it goes down the FGT on side A shows it is down in ipsec monitor on gui.

When side B comes up again I see p1 connection requests from it on side A FGT in diag debug app ike -1 output.

It does match p1 proposals and the right tunnel but then don't go further.

To mee it looks as if when the ipsec goes down when side B reboots it does get this (I assume either via DPD oder NAT Keepalive - its shown down in ipsec monitor) something is leftover and that prevents side B from establishing a new vpn conncetion until it gets removed by timeout.

Maybe it does establish P1 but then tries to re-establish old p2 which will not work until some timeout kicks it?

Does anyone have any tip or idea for me?

[emnoc]

Enable auto-negotiation on the phase2 definitions and the ipsec tunnel will always come up. You do it from the cli

   https://kb.fortinet.com/kb/documentLink.do?externalID=12069

The diag vpn tunnel list will show you want ones are not enable in the output.

Ken Felix

[sw2090]

Ken,

auto negation is always on on all my ipsec tunnels here on both side. I see in the logs that both sides try to auto negotiate. Also once that Tunnel finally has come up and I bring it down with the button in ipsec manager on gui it does go down and re-auto-negotiates within some sec.

It just does not do this when I reboot side B.

[emnoc]

How did you determine that in the logs? If one side goes down, does the other side  clears the ike and ipsec SAs? 

  diag vpn tunnel list | grep spi

  diag vpn ike gateway

If you still see IKE/IPSEC SAs than one side is stuck.  I would suggest  diagnose DPD  if you suspect DPD

diag debug reset 

diag debug enable 

diag debug application  ike -1 

diag debug enable

Monitor R U THERE messages

Alternative, run diag sniffer packet on wan interface and just for the interval and packets

e.g

    diag sniffer packet wan "host 192.0.2.1 and port 500 or 4500"

Ken Felix