Hi,
What command in gui or cli should I follow in order to see the mac-address of each interface of the fortigate firewall 100D?
Like show arp, then show mac-address in a cisco switch.
Thanks,
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.
bluephoenix71 wrote:Hi I get to see the ip address but it's mostly the VIP or HSRP ip of the core switch...
Hi Blue. I don't think you will find a complete single list/page showing the MAC Address of all the Interfaces. On the GUI you can find the MAC Address listed behind the Interface name (see pic).
emnoc has already provided the CLI commands to get the mac address, which is diag hardware deviceinfo nic <name>. Use ? in place of <name> to get a list of interfaces.
If you just want the MAC-Address for an interface, use: diag hardware deviceinfo nic <name> | grep HWaddr
NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C
Hi
what has to be noted in this comunication is following:
ARP entries on a FortiGate configured as whatever on a physical interface can be seen with the corresponding commands shown here like:
# get sys arp
# diagnose ip arp list
ARP entries like VIP ones CAN NOT BE SEEN on the arp list because they are existing in the firewall deamon on layer 4. Example: if you have one public IP on the wan1 and it is physical configured you will see the arp no problem. If you use no a second one and you DO NOT configure the second one as secondary IP on the wan1 (not needed) but instead you configure a VIP based on the second one all works from scratch as long as the second public IP is routed to the wan1 from outsite perspective. If you look to the arp tabel you will NOT see the arp entry for the second public IP because the VIP which has enabled "arp-reply yes" is existing in layer 4 or within the firewall deamon and because of this you will not see a corresponding entry in the command shown here. All commands shown here are based on layer 2 and therefore firewall deamon layer 4 arp entries you will never see. As of information of the Support of Fortinet there is no possibility or a available command which shows this entries.
By the way the same issue/situation we have for routing entries depending client2site (dial-up). This means acutally following: If you create a dial-up and you define for this connection a Office IP Pool (actually a dhcp server which gives after succesfull authentication a IP to the connecting client) you do not have actually to route this Office IP Pool to the IPSec client2site VPN because this entry is done within the IPSec deamon. Of course you can create a static entry which I really recommend because also here the routing is existing within IPSec deamon on layer 4 you will never see the routing entry on layer 3 with the corresponding routing command like:
# diagnose ip route list
Also here based on the information of Fortinet Support there is no command which shows the routing based on layer 4. This circumstances that the dial-up VPN Office Pool has not to be anymore routed and in the background the routing entry is automatically done within the IPSec deamon is for FortiOS 5.0 and higher.
hope this helps
have fun....
Andrea
If that's the case than another option diag ip arp list ;)
PCNSE
NSE
StrongSwan
This is a diagnostic command, so this is safe? can be issued during production?
emnoc wrote:If that's the case than another option diag ip arp list ;)
Hi
what has to be noted in this comunication is following:
ARP entries on a FortiGate configured as whatever on a physical interface can be seen with the corresponding commands shown here like:
# get sys arp
# diagnose ip arp list
ARP entries like VIP ones CAN NOT BE SEEN on the arp list because they are existing in the firewall deamon on layer 4. Example: if you have one public IP on the wan1 and it is physical configured you will see the arp no problem. If you use no a second one and you DO NOT configure the second one as secondary IP on the wan1 (not needed) but instead you configure a VIP based on the second one all works from scratch as long as the second public IP is routed to the wan1 from outsite perspective. If you look to the arp tabel you will NOT see the arp entry for the second public IP because the VIP which has enabled "arp-reply yes" is existing in layer 4 or within the firewall deamon and because of this you will not see a corresponding entry in the command shown here. All commands shown here are based on layer 2 and therefore firewall deamon layer 4 arp entries you will never see. As of information of the Support of Fortinet there is no possibility or a available command which shows this entries.
By the way the same issue/situation we have for routing entries depending client2site (dial-up). This means acutally following: If you create a dial-up and you define for this connection a Office IP Pool (actually a dhcp server which gives after succesfull authentication a IP to the connecting client) you do not have actually to route this Office IP Pool to the IPSec client2site VPN because this entry is done within the IPSec deamon. Of course you can create a static entry which I really recommend because also here the routing is existing within IPSec deamon on layer 4 you will never see the routing entry on layer 3 with the corresponding routing command like:
# diagnose ip route list
Also here based on the information of Fortinet Support there is no command which shows the routing based on layer 4. This circumstances that the dial-up VPN Office Pool has not to be anymore routed and in the background the routing entry is automatically done within the IPSec deamon is for FortiOS 5.0 and higher.
hope this helps
have fun....
Andrea
Hmm, the OP is looking for the list of MAC addresses of all interfaces. VIPs - as documented - use the MAC address of the associated physical interface.
So, yes, you cannot see all IP addresses in an IP-MAC table but you can see all MAC addresses in use by the FGT.
So is there not a way to assign a virtual MAC to VIPs? We have an ISP that (as a side benefit to their DOCSIS3 rollout) has to manually approve all requests when there is >1 IP/MAC.
Re-reading this - that may be a dumb question as the MAC is the hardware address and that's what's actually plugged in, but I suppose it could be possible to alter the ARP reply by the WAN interface. Just not sure if this is actually something that can be done.
Hi
to assign a MAC address to a VIP in direct way is not possible from my point of view. Anyway of course you can add a specific ARP entry as normally done on layer 2 which means if you use on the wan1 a /29 and there is an addtional /29 which is from logical point of view also on the wan1 actually it is enough if you create a VIP based on the addtional /29 and if under "config firewall vip" the option which is by standard the case "arp-reply" is enabled in layer 4 there will be ARP entries. This arp entries are not visible on layer 2 but as mentioned of course you can add classic arp entries based on this addtional /29 to the wan1 which means:
# config system arp-table # edit 1 new entry '1' added # get id : 1 interface : ip : 0.0.0.0 mac : 00:00:00:00:00:00 # set interface [Name of Interface zB "wan1"] # set ip [IPv4 Addresse] # set mac [MAC Addresse der IPv4 Addresse] # end
In this way the interface on layer 2 will answer to arp request. What is also possible is to enable within "config firewall vip" the option "gratuitous-arp-interval" which means if this option is used the layer 4 will send arp replies out to informe the switch/router etc. that this ip/arp is up etc. Normally this is used within a cluster env to inform the switch that something is up and running etc. I'm since long time in this business and if I have a customer in such situation meaning with addtional IP Range on wan1 I'm doing actually always static ARP entries only to show for future use that there is an addtional IP range. Of course you can also configure this addtional /29 as secondary on the wan1 which means if this is done it is visible on the Web Gui (because of the scondary entry on the interface) as on arp because it is based on a classic way to add arp's based on layer 2 as based on secondary interface.
For me is only important "to know that arp entries based on VIP are not based on layer 2 and not visible because they exist in layer 4" (firewall deamon).
hope this helps
have fun
Andrea
In the CLI use the following command:
diagnose hardware deviceinfo nic wan1
The MAC will be listed as "Current_HWadd".
if the cisco supports LLDP, you might want to try that,,,
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 |
---|---|
1688 | |
1087 | |
752 | |
446 | |
227 |
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.