Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
unknown1020
New Contributor III

access problems towards vpn s2s

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.

4 REPLIES 4
dbhavsar
Staff
Staff

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

DNB
unknown1020
New Contributor III

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"

hbac

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, 

unknown1020
New Contributor III

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?

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors