New Member

Solved

UNABLE TO ACCESS MY GATEWAY VIA WEB GUI OR SSH

Forum|Forum|9 months ago
August 7, 2025
6 replies
2143 views

I have my four vlans 10,20,30,40 tagged in interface internal5 then i do access my device fortigate 60f via web GUI but now i can not access the web gui again. i want solution to resolve this issue

vlan10 10.10.1.1/24
vlan20 10.10.2.1/24

vlan30 10.10.3.1/24

FortiGate

Best answer by Markus_M

Note that the article that you have there would not only specify to run

FASYL-FIREWALL # diagnose debug flow filter addr 10.10.1.1

This will only set a filter. What also needs to be done is diag debug enable and starting the trace.

To copy from that article with your IP:

diagnose debug enable

diagnose debug flow filter addr 10.10.1.1

diagnose debug flow show function-name enable
diagnose debug flow show iprope enable (this is good for routing decisions)

diagnose debug flow trace start 100

Also, the sniffer command with that IP:
diag sniffer packet any 'host 10.10.1.1' 4 0 a
would and should give output. If there is too much output, replace the 10.10.1.1 with your client host IP.
Troubleshoot with understanding what is troubleshooted - this here attempts to show what happens with a packet when it arrives at FortiGate, how it is processed and sent elsewhere:
https://docs.fortinet.com/document/fortigate/6.4.0/parallel-path-processing-life-of-a-packet/86811/packet-flow-ingress-and-egress-fortigates-without-network-processor-offloading
The sniffer command would start at the network interface.
The flow trace would be somewhere at the "kernel" part.
flow trace will show inbound packets, if they arrive, and say what happens to them, policy and routing decision.

If the flow trace shows output, share it, if possible.
If the flow trace shows no output, run the sniffer.
If the sniffer shows output, share it, if possible.
If the sniffer shows no output, your FortiGate does not receive packets from your host.
Then I'd say check the routing path from your client to the FortiGate.
The sniffer and flow trace may also show that packets arrive, but the response isn't sent or sent on the wrong interface. In that case FortiGate routing may need adjustment (config router static)

funkylicious

SuperUser

did this ever worked? has something changed ?

multiple things to check:

- do you have http/https/ssh enabled on the interface/ip that you are trying to access ? from console do, show full system interface <> and check for allowaccess ping https ssh http

- do you use custom ports for http/https/ssh ? via console check command, show full system global , which should display the ports defined for admin-ssh-port / admin-sport , connect using the correct one

- are you using trusted hosts for users ? make sure your source ip is defined in them, show full system admin should display the administrators and if they have trsuted hosts defined

L.E. firewall policies for local-in can also block access if they are misconfigured

"jack of all trades, master of none"

dingjerry_FTNT

Staff

Hi @FasylTech ,

Like @funkylicious said, the first question is, did this ever work?

I assume it worked for you in the past.

I hope that you have console access to the device. Or have you configured one IP on any interfaces other than internal5?

If yes, let's access the device via console access or GUI/SSH access via another interface directly.

1) You need to run the "diag sniffer packet" command to see whether the GUI/SSH traffic is hitting FGT via your VLAN interfaces or not.

2) If yes, run the debug flow commands to check why it did not work:

https://docs.fortinet.com/document/fortigate/7.6.3/administration-guide/54688/debugging-the-packet-flow

I don't know what your firmware version is on your FGT, but you can change the firmware version on the top left of the page once you open the link.

VinayHM

Access the device from public ip and try to collect the httpsd logs by accessing the device on vlan interface.

diag debug application httpsd -1

diag de en

FasylTechAuthor

New Member

i tried this command diagnose debug flow filter addr 10.10.1.1

nothing displayed.

FASYL-FIREWALL # diagnose debug flow filter addr 10.10.1.1

i treid this again

diag debug application httpsd -1

diag de en

see the output below

FASYL-FIREWALL # diag debug application httpsd -1
Debug messages will be on for 30 minutes.

FASYL-FIREWALL #
FASYL-FIREWALL # diag de en

FasylTechAuthor

New Member

i really need a solution to resolve this issue. my interface internal5 is the trunk/tagged port . can i assigned 10.10.1.1/24 to another port that is not connected to anything?

do do we know if there is anything blocking this ip address 10.10.1.1 from from access web GUI?

Markus_MAnswer

Staff & Editor

Note that the article that you have there would not only specify to run

FASYL-FIREWALL # diagnose debug flow filter addr 10.10.1.1

This will only set a filter. What also needs to be done is diag debug enable and starting the trace.

To copy from that article with your IP:

diagnose debug enable

diagnose debug flow filter addr 10.10.1.1

diagnose debug flow show function-name enable
diagnose debug flow show iprope enable (this is good for routing decisions)

diagnose debug flow trace start 100

Also, the sniffer command with that IP:
diag sniffer packet any 'host 10.10.1.1' 4 0 a
would and should give output. If there is too much output, replace the 10.10.1.1 with your client host IP.
Troubleshoot with understanding what is troubleshooted - this here attempts to show what happens with a packet when it arrives at FortiGate, how it is processed and sent elsewhere:
https://docs.fortinet.com/document/fortigate/6.4.0/parallel-path-processing-life-of-a-packet/86811/packet-flow-ingress-and-egress-fortigates-without-network-processor-offloading
The sniffer command would start at the network interface.
The flow trace would be somewhere at the "kernel" part.
flow trace will show inbound packets, if they arrive, and say what happens to them, policy and routing decision.

If the flow trace shows output, share it, if possible.
If the flow trace shows no output, run the sniffer.
If the sniffer shows output, share it, if possible.
If the sniffer shows no output, your FortiGate does not receive packets from your host.
Then I'd say check the routing path from your client to the FortiGate.
The sniffer and flow trace may also show that packets arrive, but the response isn't sent or sent on the wrong interface. In that case FortiGate routing may need adjustment (config router static)

FasylTechAuthor

New Member

this is my output when i run this command

diag sniffer packet any 'host 10.10.1.1' 4 0 a

below is the output

FASYL-FIREWALL # diag sniffer packet any 'host 10.10.1.1' 4 0 a
interfaces=[any]
filters=[host 10.10.1.1]
2025-08-11 12:48:12.326142 Management_VLAN out arp who-has 10.10.1.29 tell 10.10.1.1
2025-08-11 12:48:12.326150 internal5 out arp who-has 10.10.1.29 tell 10.10.1.1
2025-08-11 12:48:12.326569 Management_VLAN in arp reply 10.10.1.29 is-at 00:0c:29:0a:71:2c
2025-08-11 12:48:17.240941 Management_VLAN in arp who-has 10.10.1.1 tell 10.10.1.29
2025-08-11 12:48:17.240958 Management_VLAN out arp reply 10.10.1.1 is-at 84:39:8f:71:2f:5b
2025-08-11 12:48:17.240962 internal5 out arp reply 10.10.1.1 is-at 84:39:8f:71:2f:5b
2025-08-11 12:48:21.206082 Management_VLAN in arp who-has 10.10.1.1 tell 10.10.1.22
2025-08-11 12:48:21.206099 Management_VLAN out arp reply 10.10.1.1 is-at 84:39:8f:71:2f:5b
2025-08-11 12:48:21.206103 internal5 out arp reply 10.10.1.1 is-at 84:39:8f:71:2f:5b
2025-08-11 12:48:24.594365 Management_VLAN in arp who-has 10.10.1.1 tell 10.10.1.24
2025-08-11 12:48:24.594381 Management_VLAN out arp reply 10.10.1.1 is-at 84:39:8f:71:2f:5b
2025-08-11 12:48:24.594385 internal5 out arp reply 10.10.1.1 is-at 84:39:8f:71:2f:5b
2025-08-11 12:48:33.990601 Management_VLAN out arp who-has 10.10.1.32 tell 10.10.1.1
2025-08-11 12:48:33.990607 internal5 out arp who-has 10.10.1.32 tell 10.10.1.1
2025-08-11 12:48:33.991158 Management_VLAN in arp reply 10.10.1.32 is-at 00:0c:29:ff:65:68
2025-08-11 12:48:38.506169 Management_VLAN in arp who-has 10.10.1.1 tell 10.10.1.32
2025-08-11 12:48:38.506188 Management_VLAN out arp reply 10.10.1.1 is-at 84:39:8f:71:2f:5b
2025-08-11 12:48:38.506192 internal5 out arp reply 10.10.1.1 is-at 84:39:8f:71:2f:5b
2025-08-11 12:48:46.766306 Management_VLAN in 10.10.1.24.4207 -> 10.10.1.1.60938: fin 2051669467 ack 204398814
id=65308 trace_id=5 func=print_pkt_detail line=5879 msg="vd-root:00received a packet(proto=6, 10.10.2.112:61174->10.10.1.1:4433) tun_id=0.0.0.0 from AP_VLAN20. flag [S], seq 3860751215, ack 0, win 64240"
id=65308 trace_id=5 func=init_ip_session_common line=6070 msg="allocate a new session-0039b35e"
id=65308 trace_id=5 func=iprope_dnat_check line=5472 msg="in-[AP_VLAN20], out-[]"
id=65308 trace_id=5 func=iprope_dnat_tree_check line=834 msg="len=0"
id=65308 trace_id=5 func=iprope_dnat_check line=5497 msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000"
id=65308 trace_id=5 func=vf_ip_route_input_common line=2612 msg="find a route: flag=84000000 gw-10.10.1.1 via root"
id=65308 trace_id=5 func=iprope_access_proxy_check line=458 msg="in-[AP_VLAN20], out-[], skb_flags-02000000, vid-0"
id=65308 trace_id=5 func=__iprope_check line=2395 msg="gnum-100017, check-ffffffbffc02c5f4"
id=65308 trace_id=5 func=iprope_policy_group_check line=4892 msg="after check: ret-no-match, act-accept, flag-00000000, flag2-00000000"
id=65308 trace_id=5 func=__iprope_fwd_check line=807 msg="in-[AP_VLAN20], out-[Management_VLAN], skb_flags-02000000, vid-0, app_id: 0, url_cat_id: 0"
id=65308 trace_id=5 func=__iprope_tree_check line=528 msg="gnum-100004, use int hash, slot=87, len=2"
id=65308 trace_id=5 func=__iprope_check_one_policy line=2131 msg="checked gnum-100004 policy-8, ret-matched, act-accept"
id=65308 trace_id=5 func=__iprope_user_identity_check line=1894 msg="ret-matched"
id=65308 trace_id=5 func=__iprope_check line=2395 msg="gnum-4e20, check-ffffffbffc02c5f4"
id=65308 trace_id=5 func=__iprope_check_one_policy line=2131 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept"
id=65308 trace_id=5 func=__iprope_check_one_policy line=2131 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept"
id=65308 trace_id=5 func=__iprope_check_one_policy line=2131 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept"
id=65308 trace_id=5 func=__iprope_check line=2412 msg="gnum-4e20 check result: ret-no-match, act-accept, flag-00000000, flag2-00000000"
id=65308 trace_id=5 func=get_new_addr line=1265 msg="find SNAT: IP-10.10.1.1(from IPPOOL), port-61174"
id=65308 trace_id=5 func=__iprope_check_one_policy line=2365 msg="policy-8 is matched, act-accept"

FasylTechAuthor

New Member

look at what my system admin is showing as output
show system admin
config system admin
edit "admin"
set trusthost1 10.10.1.0 255.255.255.0
set accprofile "super_admin"
set vdom "root"
set password ENC SH2UJCqkvulE7Gs99yY0lWpt526bMnhh+NdEYzSXwx9tjSge3iuSFoqssJXOfg=
next
end

instead of 10.10.1.1/24 is showing 10.10.1.0/24
could this be the reason why i could not access my device ip address via web gui

please, i want a solution to return my system admin to 10.10.1.1/24

dingjerry_FTNT

Staff

Hi @FasylTech ,

1) "10.10.1.0/24" in your "config system admin" configuration is a trust host setting. This is not your Internal5 IP. It's for source IP filtering.

2) The outputs of "diag sniffer packet" showed a lot of ARP packets.

What is your client IP accessing the Web GUI? In the outputs of "debug flow", I do not see any client IP from the 10.10.1.0/24 subnet, only 10.10.2.112 trying to access 10.10.1.1:4433. This IP will be denied for Web GUI access due to the trust host setting.

3) I assume that the Management_VLAN has the 10.10.1.1 IP, correct?

4) If yes, did you enable HTTP/HTTPS in the Management_VLAN setting?

5) It's better to attach your FGT config.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded