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
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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....
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
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...
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
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
PCNSE
NSE
StrongSwan
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...
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
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
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
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?
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
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
PCNSE
NSE
StrongSwan
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.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
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
PCNSE
NSE
StrongSwan
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1679 | |
1085 | |
752 | |
446 | |
226 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.