Good morning friends, could you help me with this problem please.
There is an s2s tunnel created in the FG, this tunnel has been created for more than a year and works since it is located in UP. However, it is required that from the headquarters of the other firewall they access an internal publication https://x.y.w.z:xxxx (access with the internal IP), however from the remote headquarters they have icmp arrival but not telnet and it is not possible to access the service Web.
The client tells us that he carried out a test, from the user's PC that is located in the remote headquarters and configured the internal dns of the local organization and if access was achieved.
The policy validates that the internal IP of the web publication and the port are added, but even so access is not possible. It is worth mentioning that the segments have been added to the selectors
What could be missing.
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.
Hi @unknown1020
- Can you confirm that required services are allowed in the policy for incoming traffic. Also please collect following debugs:
diagnose debug reset
diagnose debug flow filter addr xx.xx.xx.xx yy.yy.yy and <---xx is SourceIP and yy is DestinationIP
diagnose debug flow filter port <port-on which you are trying>
diagnose debug flow show function enable
diagnose debug flow show iprope enable
diagnose debug console timestamp enable
diagnose debug flow trace start 999
diagnose debug enable
2024-04-23 15:46:03 id=65308 trace_id=2 func=__iprope_check_one_policy line=2051 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2024-04-23 15:46:03 id=65308 trace_id=2 func=__iprope_check_one_policy line=2051 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2024-04-23 15:46:03 id=65308 trace_id=2 func=__iprope_check_one_policy line=2051 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2024-04-23 15:46:03 id=65308 trace_id=2 func=__iprope_check_one_policy line=2051 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2024-04-23 15:46:03 id=65308 trace_id=2 func=__iprope_check_one_policy line=2051 msg="checked gnum-10000f policy-4294967295, ret-matched, act-accept"
2024-04-23 15:46:03 id=65308 trace_id=2 func=__iprope_check_one_policy line=2269 msg="policy-4294967295 is matched, act-drop"
2024-04-23 15:46:03 id=65308 trace_id=2 func=__iprope_check line=2316 msg="gnum-10000f check result: ret-matched, act-drop, flag-00000801, flag2-00000000"
2024-04-23 15:46:03 id=65308 trace_id=2 func=iprope_policy_group_check line=4720 msg="after check: ret-matched, act-drop, flag-00000801, flag2-00000000"
2024-04-23 15:46:03 id=65308 trace_id=2 func=fw_local_in_handler line=606 msg="iprope_in_check() check failed on policy 0, drop"
Hi @unknown1020,
Debug output is incomplete as we can't see incoming and outgoing interfaces. However, we see "iprope_in_check() check failed on policy 0, drop" which means no firewall policy matched and dropped by implicit deny policy.
Regards,
but in the firewall, within the ipsec policies the destination IP and port are added. Additionally, the segment has been added to the tunnel.
So could it be a problem with the other firewall?
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 |
---|---|
1732 | |
1106 | |
752 | |
447 | |
240 |
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.