Hello team!!!
We have 2 FGT100F in HA and configured interfaces called "mgmt" as "in band"
Now we need to access from a computer in any other interface and get:
150.0.0.4 is the IP of Fortigate HA in a specific VLAN and 150.0.0.3 is another device in the same VLAN.
I know this is a public IP, but this is complicated to change the IP in all the devices in this VLAN.
From 150.0.0.3 I can ping 150.0.0.4, but not the HA IP on mgmt interface
From another device in mgmt interface, I can ping the HA IP on mgmt interface, and each Fortigate as well
Previously, we had disabled src-check in mgmt interface
I tried to add a local-in policy to allow this (config firewall local-in-policy), but still the same behavior
We need to access to Fortigate from any VLAN, using the IP on the mgmt interface. Is this possible?
Thanks in advance.
Regards,
Damián
Solved! Go to Solution.
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.
Created on 09-25-2024 03:19 PM Edited on 09-25-2024 03:21 PM
If you're using 150.0.0.4 to access the FGT, yes, you don't need the policy. That gives you access only to the primary. But if you use 192.168.29.8 while you're coming from VL10_LAN-Kompus interface, you need a policy. You can test this by just pining it. You shouldn't be able to ping the mgmt IP from VL10_LAN-Kompus without the policy.
Toshi
Thanks for your response!
This is the routing table:
fw-ha01b # get router info routing-t all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
V - BGP VPNv4
* - candidate default
Routing table for VRF=0
S* 0.0.0.0/0 [1/0] via GW3, port9, [1/0]
[1/0] via GW1, port7, [1/0]
S 10.0.0.0/24 [10/0] via 150.0.0.3, VL10_LAN-Kompus, [1/0]
C 10.0.1.0/24 is directly connected, VL40_Borde
S 10.0.5.0/24 [10/0] via 150.0.0.3, VL10_LAN-Kompus, [1/0]
C 10.0.31.0/24 is directly connected, VL31_AP
C 10.0.32.0/24 is directly connected, VL32_WiFi-Invit
C 10.0.34.0/24 is directly connected, VL34_WiFi-Prod
C 10.0.36.0/23 is directly connected, VL36_WiFi-Corp
C 10.0.38.0/24 is directly connected, VL38_WiFi-IT
C 10.0.60.0/24 is directly connected, VL60_LAN-Gral
S 10.70.0.0/24 [10/0] via 150.0.0.3, VL10_LAN-Kompus, [1/0]
S 10.150.100.0/24 [10/0] via VPN_InsideOne tunnel 168.195.52.98, [1/0]
C 150.0.0.0/16 is directly connected, VL10_LAN-Kompus
C Network3/29 is directly connected, port9
C Network1/29 is directly connected, port7
C 192.168.28.0/24 is directly connected, VL20_Tel
C 192.168.29.0/24 is directly connected, mgmt
C 192.168.40.0/24 is directly connected, VL11_LAN-MasPro
S 192.168.100.0/28 [10/0] via 150.0.0.2, VL10_LAN-Kompus, [1/0]
C 192.168.100.80/28 is directly connected, VL105_Granja-Cu
C 192.168.100.96/28 is directly connected, VL106_DMZ_Cuida
Yes, this is on the routing table.
IMHO, I dont think I need a policy "VL10_LAN-Kompus -> mgmt", because I dont need to go to devices on mgmt interface, I need to access to Fortigate itself.
Anyway, when I have some time I could try
This sound to me, like Jhonathan said, an issue with local-in-policies, but I have tried to allow this with no success.
Thanks
Regards,
Created on 09-25-2024 03:19 PM Edited on 09-25-2024 03:21 PM
If you're using 150.0.0.4 to access the FGT, yes, you don't need the policy. That gives you access only to the primary. But if you use 192.168.29.8 while you're coming from VL10_LAN-Kompus interface, you need a policy. You can test this by just pining it. You shouldn't be able to ping the mgmt IP from VL10_LAN-Kompus without the policy.
Toshi
You were right, when I add a rule to allow this, started to work.
The output of the debug I posted made me think wrong.
Thank you a lot!
Regards,
Damián
Created on 09-26-2024 07:46 AM Edited on 09-26-2024 07:47 AM
No. Thank YOU. I owe you about HA in-band management-IP usage explained in below KB.
https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-implement-In-Band-Management-interf...
But the bottom line is with FGTs any inter-interface traffic requires a policy. Your setup is the same when you use a loopback interface to terminate IPsec VPNs, which requires a policy from/to an inbound interface to/from the loopback interface. That's why I don't like/use a loopback interface for that purpose.
Toshi
Can you post the output of "show system interface"?
(you can remove public addresses from the output)
Hello AEK, thanks for your response.
Ok, I paste the output next to this line, this is too much because we have many VLANs and WANs.
config system interface
edit "dmz"
set vdom "root"
set ip 10.10.10.1 255.255.255.0
set allowaccess ping https fabric
set type physical
set role dmz
set snmp-index 1
next
edit "mgmt"
set vdom "root"
set management-ip 192.168.29.8 255.255.255.0
set ip 192.168.29.5 255.255.255.0
set allowaccess ping https ssh snmp
set type physical
set src-check disable
set role lan
set snmp-index 2
next
edit "wan1"
set vdom "root"
set allowaccess ping https
set type physical
set role wan
set snmp-index 3
next
edit "wan2"
set vdom "root"
set mode dhcp
set allowaccess ping
set type physical
set role wan
set snmp-index 4
next
edit "ha1"
set vdom "root"
set type physical
set snmp-index 5
next
edit "ha2"
set vdom "root"
set type physical
set snmp-index 6
next
edit "port1"
set vdom "root"
set type physical
set alias "Trunk-LAN"
set snmp-index 15
next
edit "port2"
set vdom "root"
set type physical
set snmp-index 16
next
edit "port3"
set vdom "root"
set type physical
set alias "Trunk-WLAN"
set snmp-index 17
next
edit "port4"
set vdom "root"
set type physical
set snmp-index 18
next
edit "port5"
set vdom "root"
set type physical
set snmp-index 19
next
edit "port6"
set vdom "root"
set type physical
set snmp-index 20
next
edit "port7"
set vdom "root"
set ip 190.221.139.91 255.255.255.248
set allowaccess ping https
set type physical
set alias "WAN1-ClaroFO"
set lldp-reception enable
set monitor-bandwidth enable
set role wan
set snmp-index 21
next
edit "port8"
set vdom "root"
set allowaccess ping https
set type physical
set alias "WAN2-ClaroRF"
set lldp-reception enable
set role wan
set snmp-index 22
next
edit "port9"
set vdom "root"
set ip 181.15.149.238 255.255.255.248
set allowaccess ping https
set type physical
set alias "WAN3-Telecom"
set lldp-reception enable
set monitor-bandwidth enable
set role wan
set snmp-index 23
next
edit "port10"
set vdom "root"
set allowaccess ping https
set type physical
set alias "WAN4-Fibercorp"
set lldp-reception enable
set role wan
set snmp-index 24
next
edit "port11"
set vdom "root"
set allowaccess ping https
set type physical
set alias "WAN5-Fibertel"
set lldp-reception enable
set role wan
set snmp-index 25
next
edit "port12"
set vdom "root"
set type physical
set snmp-index 26
next
edit "x1"
set vdom "root"
set type physical
set mediatype sr
set snmp-index 7
set speed 10000full
next
edit "x2"
set vdom "root"
set type physical
set mediatype sr
set snmp-index 8
set speed 10000full
next
edit "port13"
set vdom "root"
set type physical
set snmp-index 27
set speed 1000full
next
edit "port14"
set vdom "root"
set type physical
set snmp-index 28
set speed 1000full
next
edit "port15"
set vdom "root"
set type physical
set snmp-index 29
set speed 1000full
next
edit "port16"
set vdom "root"
set type physical
set snmp-index 30
set speed 1000full
next
edit "port17"
set vdom "root"
set type physical
set snmp-index 31
set speed 1000full
next
edit "port18"
set vdom "root"
set type physical
set snmp-index 32
set speed 1000full
next
edit "port19"
set vdom "root"
set type physical
set role lan
set snmp-index 14
set speed 1000full
next
edit "port20"
set vdom "root"
set type physical
set role lan
set snmp-index 13
set speed 1000full
next
edit "modem"
set vdom "root"
set mode pppoe
set status down
set type physical
set snmp-index 9
next
edit "naf.root"
set vdom "root"
set type tunnel
set src-check disable
set snmp-index 33
next
edit "l2t.root"
set vdom "root"
set type tunnel
set snmp-index 34
next
edit "ssl.root"
set vdom "root"
set type tunnel
set alias "SSL VPN interface"
set snmp-index 10
next
edit "lan"
set vdom "root"
set allowaccess ping https ssh fabric
set type hard-switch
set stp enable
set role lan
set snmp-index 11
next
edit "fortilink"
set vdom "root"
set fortilink enable
set ip 169.254.1.1 255.255.255.0
set allowaccess ping fabric
set type aggregate
set member "x1" "x2"
set lldp-reception enable
set lldp-transmission enable
set snmp-index 12
next
edit "VL10_LAN-Kompus"
set vdom "root"
set ip 150.0.0.4 255.255.0.0
set allowaccess ping https
set device-identification enable
set role lan
set snmp-index 35
set ip-managed-by-fortiipam disable
set interface "port1"
set vlanid 10
next
edit "VL32_WiFi-Invit"
set vdom "root"
set ip 10.0.32.1 255.255.255.0
set allowaccess ping
set device-identification enable
set role lan
set snmp-index 36
set ip-managed-by-fortiipam disable
set interface "port3"
set vlanid 32
next
edit "VL34_WiFi-Prod"
set vdom "root"
set ip 10.0.34.1 255.255.255.0
set allowaccess ping
set device-identification enable
set role lan
set snmp-index 37
set ip-managed-by-fortiipam disable
set interface "port3"
set vlanid 34
next
edit "VL36_WiFi-Corp"
set vdom "root"
set ip 10.0.36.1 255.255.254.0
set allowaccess ping
set device-identification enable
set role lan
set snmp-index 38
set ip-managed-by-fortiipam disable
set interface "port3"
set vlanid 36
next
edit "VL1_Default"
set vdom "root"
set device-identification enable
set role lan
set snmp-index 39
set ip-managed-by-fortiipam disable
set interface "port1"
set vlanid 1
next
edit "VL11_LAN-MasPro"
set vdom "root"
set ip 192.168.40.7 255.255.255.0
set allowaccess ping https
set device-identification enable
set role lan
set snmp-index 40
set ip-managed-by-fortiipam disable
set interface "port1"
set vlanid 11
next
edit "VL20_Tel"
set vdom "root"
set ip 192.168.28.3 255.255.255.0
set allowaccess ping https
set device-identification enable
set role lan
set snmp-index 41
set ip-managed-by-fortiipam disable
set interface "port1"
set vlanid 20
next
edit "VL40_Borde"
set vdom "root"
set ip 10.0.1.3 255.255.255.0
set allowaccess ping https
set device-identification enable
set role lan
set snmp-index 42
set ip-managed-by-fortiipam disable
set interface "port1"
set vlanid 40
next
edit "VL105_Granja-Cu"
set vdom "root"
set ip 192.168.100.83 255.255.255.240
set allowaccess ping https
set device-identification enable
set role lan
set snmp-index 43
set ip-managed-by-fortiipam disable
set interface "port1"
set vlanid 105
next
edit "VL106_DMZ_Cuida"
set vdom "root"
set ip 192.168.100.104 255.255.255.240
set allowaccess ping https
set device-identification enable
set role lan
set snmp-index 44
set ip-managed-by-fortiipam disable
set interface "port1"
set vlanid 106
next
edit "VL31_AP"
set vdom "root"
set ip 10.0.31.1 255.255.255.0
set allowaccess ping https
set device-identification enable
set role lan
set snmp-index 45
set ip-managed-by-fortiipam disable
set interface "port3"
set vlanid 31
next
edit "VL60_LAN-Gral"
set vdom "root"
set ip 10.0.60.1 255.255.255.0
set allowaccess ping https
set device-identification enable
set role lan
set snmp-index 46
set ip-managed-by-fortiipam disable
set interface "port1"
set vlanid 60
next
edit "VPN_InsideOne"
set vdom "root"
set type tunnel
set snmp-index 47
set interface "port9"
next
edit "VL38_WiFi-IT"
set vdom "root"
set ip 10.0.38.1 255.255.255.0
set allowaccess ping https
set device-identification enable
set role lan
set snmp-index 48
set ip-managed-by-fortiipam disable
set interface "port3"
set vlanid 38
next
end
Sorry, another question related to this.
Now, after add the IPv4 policy to allow access from VLAN10 to mgmt.
From VLAN10:
I can ping the cluster IP in the mgmt interface (192.168.29.5)
I can ping the active FGT management-ip in the mgmt interface (192.168.29.8)
I cannot ping the pasive FGT management-ip in the mgmt interface (192.168.29.9)
I did a debug in passive FGT and nothing was showed
I did a debug in active FGT and I get this:
id=65308 trace_id=101 func=print_pkt_detail line=5879 msg="vd-root:0 received a packet(proto=1, 150.0.0.241:1->192.168.29.9:2048) tun_id=0.0.0.0 from VL10_LAN-Kompus. type=8, code=0, id=1, seq=791."
id=65308 trace_id=101 func=init_ip_session_common line=6063 msg="allocate a new session-0728f54f"
id=65308 trace_id=101 func=vf_ip_route_input_common line=2612 msg="find a route: flag=04000000 gw-192.168.29.9 via mgmt"
id=65308 trace_id=101 func=__iprope_tree_check line=528 msg="gnum-100004, use int hash, slot=78, len=3"
id=65308 trace_id=101 func=get_new_addr line=1265 msg="find SNAT: IP-192.168.29.5(from IPPOOL), port-60418"
id=65308 trace_id=101 func=fw_forward_handler line=987 msg="Allowed by Policy-24: SNAT"
id=65308 trace_id=101 func=__ip_session_run_tuple line=3429 msg="SNAT 150.0.0.241->192.168.29.5:60418"
From another computer in the same segment of mgmt interface, I can ping all this 3 IPs.
Any idea?
Thanks in advance.
Regards,
Damián
Created on 09-27-2024 05:08 PM Edited on 09-27-2024 05:17 PM
I'm now not so sure if accessing the "management-ip" on the secondary from a VLAN interface would work.
As in the "management-ip" KB I referrd above, it seems to be designed to be accessible from outside coming directly to the physical interface (of course both sides are on the same broadcast domain via a switch) as depicted in the diagram. So if you access the secodary's management-ip, it never hits or comes through the primary. That's why it works.
On the other hand, if you're coming from another interface configured on both units, your access to the secondary's management-ip always arrives at the primary on the VLAN interface. But based on my simple test: pinging from the primary to the secondary's management-ip doesn't get any reply. While pinging from the secondary to the primary's management-ip gets replies. So unless my test setup is erroneous, if it's coming from another interface arriving at the primary it wouldn't work.
However, I'm still not 100% sure about the design so I could be wrong as well as my test environment. You likely need to open a ticket at TAC to get it tested by TAC person in a remote session.
Toshi
Ok, anyway, thanks for everything.
Regards,
Damián
Created on 09-28-2024 10:34 AM Edited on 09-28-2024 10:49 AM
And, I understand why you had to choose "in-band" because you're coming from another interface on the same FGT.
But if this in fact doesn't work to get to the secondary, I don't see much benefit of this "in-band" management-ip. If it has to come from outside directly reaching both units' interfaces you configure individual IPs, configuring out-of-band IPs on the dedicated mgmt interface then coming from outside/switch side to reach them is more clear-cut and has no impact to the user traffic.Only additional part is two more cables from the switch and some routing outside of the FGT.
If HA is up, you can always get to the primary then jump into the secondary with "exe ha manage [0|1] <admin_username>" for CLI. No GUI admin though.
When you really need to access the secondary directly, it's almost always when you need to deal with HA related issues. For troubleshooting those issues at secondary, you have to use CLI anyway. So using an out-of-band mgmt, or (remote) console, with CLI is necessary for most of those situations.
Toshi
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 |
---|---|
1645 | |
1070 | |
751 | |
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.