How can I now see what port in core-sw1 or core-sw2 is connected to fortigate por16? Do I really need someone physically onsite to trace this? Now, port 15 and 16 are configured as bonded or only having one IP address. +-+-+-+-ġ08 085b.0e5d.3312 dynamic ip GigabitEthernet4/21īUT.if I trace the second mac-address it is not showing on both core switches.ĬOR-1# show mac address-table add 08:5b:0e:5d:33:13 If I do a show mac address-table add on core-sw1, I can see that it's in g4/21.ĬOR-1# show mac address-table add 08:5b:0e:5d:33:12 Now, what I need to is to exactly trace what port port 15 and port 16 connects to the switch, in this case a cisco switch. Thanks for the commands, I can see 2 mac-addresses on port15 and port 16įwb01 # get hardware nic port15 | grep -A 2 "Current"įwb01 # get hardware nic port16 | grep -A 2 "Current"
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. 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:Īlso here based on the information of Fortinet Support there is no command which shows the routing based on layer 4. 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. As of information of the Support of Fortinet there is no possibility or a available command which shows this entries.īy the way the same issue/situation we have for routing entries depending client2site (dial-up). All commands shown here are based on layer 2 and therefore firewall deamon layer 4 arp entries you will never see. 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. 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. Example: if you have one public IP on the wan1 and it is physical configured you will see the arp no problem. What has to be noted in this comunication is following:ĪRP entries on a FortiGate configured as whatever on a physical interface can be seen with the corresponding commands shown here like:ĪRP entries like VIP ones CAN NOT BE SEEN on the arp list because they are existing in the firewall deamon on layer 4.
0 kommentar(er)
