Hiho,
unfortunately the FGTs seem to still ignore IKE Debug Log Filters. No matter if I set "diag vpn ike log-filter name ..." or "diag vpn ike log filter name ..." or "diag vpn ike filter name ..." or all four even, still if I switch on "diag application ike -1" and then "diag debug enable" I get the log outputted unfiltered even though there should be filters now. I see them if I use the corresponding option "list" to output the corresponding filter list.
This is very annoying as it makes ipsec debugging very hard once you have some more tunnels :(
--
"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.
This is since I started working with these devices. Just filter on the dst-addr4 field, this works every time for me.
src-addr4 or dst-addr4 don't help me much since there is severy ipsec tunnels from and to the specific ip.
This would only work if I were testing from outside office.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
Only one IPSec can be established with a given source-and-destination pair.
toshiesumi wrote:Only one IPSec can be established with a given source-and-destination pair.
For the sake of correctness, there can be multiple IKE SAs between same VPN peers. See Two IKE SAs for a single Phase1 configuration.
Thank you for the correction. I meant one pair of SAs by one IPsec.
Just a note on this if you will.
diagnose vpn ike log filter dst-addr4 x.x.x.x <-- this works diagnose vpn ike filter dst-addr4 x.x.x.x <-- does not work
At lease thats what I experienced. OS 5.2.7
- FortiFr34k11
This is what i do for regular site-2-sites for dialup I use the client address once provided
diag debug app ike filter name "phase1-name"
diag debug app ike -1
diag debug enable
PCNSE
NSE
StrongSwan
Hi,
I recently opened a ticket about the odd behaviour/misleading documentation about the "name" filter, and this is the explanation I was given:
Below are some IKE debug lines to use as a reference for the explanation. The lines I have highlighted in bold contains the name of the phase1 to which they apply, here: "test" ALL other lines do NOT contain a name. This is the KEY to understanding how this filter works. So, if your IKE filter is: # diag vpn ike log filter name "test" then you will see all these lines. If your IKE filter is: # diag vpn ike log filter name "PARIS" then you will still see ALL the lines WITHOUT a name. ONLY the lines with a name (here, "test") will be filtered. So, the behavior is: - lines without a name are always shown - lines with a name are filtered based on the configured name filter: "diag vpn ike log filter name XXXX" =========== (not bold) ike 0: comes 192.168.230.15:500->192.168.230.56:500,ifindex=3.... ike 0: IKEv1 exchange=Aggressive id=5bd0b0133fee73f3/0000000000000000 len=508 ike 0:5bd0b0133fee73f3/0000000000000000:63343: responder: aggressive mode get 1st message... ike 0:5bd0b0133fee73f3/0000000000000000:63343: VID CISCO-UNITY 12F5F28C457168A9702D9FE274CC0100 ike 0:5bd0b0133fee73f3/0000000000000000:63343: VID RFC 3947 4A131C81070358455C5728F20E95452F ike 0:5bd0b0133fee73f3/0000000000000000:63343: VID draft-ietf-ipsec-nat-t-ike-02 CD60464335DF21F87CFDB2FC68B6A448 ike 0:5bd0b0133fee73f3/0000000000000000:63343: VID draft-ietf-ipsec-nat-t-ike-02\n 90CB80913EBB696E086381B5EC427B1F ike 0:5bd0b0133fee73f3/0000000000000000:63343: VID draft-ietf-ipsra-isakmp-xauth-06.txt 09002689DFD6B712 ike 0:5bd0b0133fee73f3/0000000000000000:63343: VID DPD AFCAD71368A1F1C96B8696FC77570100 ike 0:5bd0b0133fee73f3/0000000000000000:63343: VID forticlient connect license 4C53427B6D465D1B337BB755A37A7FEF ike 0:5bd0b0133fee73f3/0000000000000000:63343: VID Fortinet Endpoint Control B4F01CA951E9DA8D0BAFBBD34AD3044E ike 0::63343: peer identifier IPV4_ADDR 192.168.230.15 ike 0: IKEv1 Aggressive, comes 192.168.230.15:500->192.168.230.56 3 ike 0:5bd0b0133fee73f3/0000000000000000:63343: negotiation result ike 0:5bd0b0133fee73f3/0000000000000000:63343: proposal id = 1: ike 0:5bd0b0133fee73f3/0000000000000000:63343: protocol id = ISAKMP: ike 0:5bd0b0133fee73f3/0000000000000000:63343: trans_id = KEY_IKE. ike 0:5bd0b0133fee73f3/0000000000000000:63343: encapsulation = IKE/none ike 0:5bd0b0133fee73f3/0000000000000000:63343: type=OAKLEY_ENCRYPT_ALG, val=AES_CBC, key-len=128 ike 0:5bd0b0133fee73f3/0000000000000000:63343: type=OAKLEY_HASH_ALG, val=SHA. ike 0:5bd0b0133fee73f3/0000000000000000:63343: type=AUTH_METHOD, val=PRESHARED_KEY. ike 0:5bd0b0133fee73f3/0000000000000000:63343: type=OAKLEY_GROUP, val=MODP1536. ike 0:5bd0b0133fee73f3/0000000000000000:63343: ISAKMP SA lifetime=120 ike 0:5bd0b0133fee73f3/0000000000000000:63343: SA proposal chosen, matched gateway test (bold) ike 0:test: created connection: 0xd63a700 3 192.168.230.56->192.168.230.15:500. ike 0:test: HA L3 state 1/0 ike 0:test:63343: DPD negotiated ike 0:test:63343: XAUTHv6 negotiated ike 0:test:63343: peer supports UNITY ike 0:test:63343: enable FortiClient license check
In my opinion, the behaviour of the "name" filter does not match the documentation, and either one ought to be fixed.
"For now", they refuse to do either, claiming that "this is by design" and that nothing is wrong.
If you believe that the "name" filter should work like the src4/dst4 filters, open a ticket and voice your opinion.
the last time i used it it did not really work :(
I set: diag vpn ike log filter name "name-of-phase1"
and then started diag debug app ike -1
And in the output I still see a lot of lines that contain different p1 names. I wouldn't mind lines with no name because e.g. the handshake of the proposals at the beginning of p1 doesn't have a name yet.
But I would like to be able to filter all containing either no name or the given p1 name and that at my side did not work.
Just tried again...does not work...diag debug app ike -1 seems not to care for that filter.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
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 |
---|---|
1547 | |
1031 | |
749 | |
443 | |
210 |
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.