Skip to main content
sw2090
SuperUser
SuperUser
March 4, 2020
Question

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

  • March 4, 2020
  • 12 replies
  • 7919 views

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

    12 replies

    sw2090
    SuperUser
    sw2090Author
    SuperUser
    March 4, 2020

    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
    SuperUser
    sw2090Author
    SuperUser
    March 4, 2020

    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
    New Member
    March 4, 2020

    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

     

    Thought Leadership Security Summit. Outpace New Threats with AI - enhanced defense. Tuesday, Septmeber 15, 8:30 AM - 2:30 PM PT. The Golf Club at Newcastle, WA.
    Virtual event | September 2026. SASE summit. The age of autonomous trust. Register here!