Skip to main content
A
Anonymous_User
Contributor
May 21, 2007
Question

' Interface Mode' not working

  • May 21, 2007
  • 7 replies
  • 3858 views
Hi, On a Fortigate 200A you have several interfaces. 2 WAN, 2 DMZ and 1 4-port switch. According to FortiGate_Administration_Guide_01-30004-0203-20070102.pdf on page 71, It should be possible to put the switch into interface mode to be able to configure the interfaces of the 4-Port switch individually. This isn’t working. Below I’m posting what I did to troubleshoot the issue. Please give feedback. Fortigate-200A 3.00,build0413,070503 -- DEFAULT CONFIG (switch mode) -- FG200A3906503468 # sh system interface config system interface edit " internal" set vdom " root" set ip 192.168.1.99 255.255.255.0 set allowaccess ping https set type physical next edit " dmz1" set vdom " root" set ip 10.10.10.1 255.255.255.0 set allowaccess ping https set type physical next edit " dmz2" set vdom " root" set allowaccess ping set type physical next edit " wan1" set vdom " root" set ip 192.168.100.99 255.255.255.0 set allowaccess ping https telnet set type physical next edit " wan2" set vdom " root" set allowaccess ping set type physical next end -- PING FROM 192.168.1.5 to internal (192.168.1.99) -- C:\>ping 192.168.1.99 Pinging 192.168.1.99 with 32 bytes of data: Reply from 192.168.1.99: bytes=32 time<1ms TTL=255 Reply from 192.168.1.99: bytes=32 time<1ms TTL=255 Reply from 192.168.1.99: bytes=32 time<1ms TTL=255 Reply from 192.168.1.99: bytes=32 time<1ms TTL=255 Ping statistics for 192.168.1.99: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms -- MONITORING ‘INTERNAL (192.168.1.99) -- FG200A3906503468 # diag snif pa internal icmp interfaces=[internal] filters=[icmp] 1.034718 192.168.1.5 -> 192.168.1.99: icmp: echo request 1.034776 192.168.1.99 -> 192.168.1.5: icmp: echo reply 2.037005 192.168.1.5 -> 192.168.1.99: icmp: echo request 2.037064 192.168.1.99 -> 192.168.1.5: icmp: echo reply 3.039301 192.168.1.5 -> 192.168.1.99: icmp: echo request 3.039364 192.168.1.99 -> 192.168.1.5: icmp: echo reply 4.041571 192.168.1.5 -> 192.168.1.99: icmp: echo request 4.041632 192.168.1.99 -> 192.168.1.5: icmp: echo reply -- CHANGIING TO INTERFACE MODE -- !!! DELETE DEFAULT FIREWALL POLICY BECAUSE SETTING IS IN USE !!! ‘System’ -> ‘Network’ -> ‘Switch Mode’ Change ‘Switch Mode’ into ‘Interface Mode’ -- RESULTING INTO A NEW INTERFACE CONFIGURATION: -- FG200A3906503468 # sh system interface config system interface edit " dmz1" set vdom " root" set ip 10.10.10.1 255.255.255.0 set allowaccess ping https set type physical next edit " dmz2" set vdom " root" set allowaccess ping set type physical next edit " wan1" set vdom " root" set ip 192.168.100.99 255.255.255.0 set allowaccess ping https telnet set type physical next edit " wan2" set vdom " root" set allowaccess ping set type physical next edit " internal1" set vdom " root" set type physical next edit " internal2" set vdom " root" set type physical next edit " internal3" set vdom " root" set type physical next edit " internal4" set vdom " root" set type physical next end -- GIVING INTERNAL 1 A VALID IP ADRESS -- FG200A3906503468 # sh system interface internal1 config system interface edit " internal1" set vdom " root" set ip 192.168.1.99 255.255.255.0 set allowaccess ping https telnet set type physical next end -- pinging from 192.168.1.5 to INTERNAL1 (192.168.1.99) -- Request timed out Request timed out Request timed out Request timed out -- MONITORING INTERNAL1 (192.168.1.99) -- FG200A3906503468 # dia snif pa internal1 icmp interfaces=[internal1] filters=[icmp] pcap_open_live: ioctl: No such device for internal1 ????????????????????

    7 replies

    UkWizard
    UkWizard
    New Member
    May 21, 2007
    Have you done all the configuration in the CLI? or the GUI? Log into the GUI and check that the interface names are internal1, internal2 etc. Its just a thought, as the edit cli command sometimes seems to allow invalid interface names sometimes. I presume you do have the network cable in the Internal1 port as well :)
    UkWizard
    UkWizard
    New Member
    May 21, 2007
    Also; I presume you noted the comments of the pre-requisites before changing the mode, the manual states; Caution: Before you are able to switch between Switch Mode and Interface Mode all references to ‘internal’ interfaces must be removed. This includes references such as firewall policies, VDOM interface assignments, VLANS, and routing. You might also want to delete the arp cache on the host/device you are pinging, as if the mac changes during this process, the pings would fail until the arp has been refereshed. (eg. if pinging an windows host, type the following to clear it out; arp -d 192.168.1.99)
    A
    Anonymous_UserAuthor
    Contributor
    May 21, 2007
    Thanks for your reply UkWizard, 1)I' ve done the configuration in the GUI. in other words, changing from ' switch mode' to ' Interface Mode' was done in the GUI, as well as assigning the IP adres to internal1. When I changed the mode, ' internal' became ' internal1' & ' internal2' etc... It looked ok in the GUI aswell as in the CLI 2) yes, there is a network cable in internal1 =) a machine is connected to it, with ' ping 192.168.1.99 -t' running 3) I' ve noticed the pre-requisites and deleted the default Firewall entry. (All internal is allowed through all WAN1). This was indeed necessary to allow the switching. Otherwise it gives an error ' something something in use' 4) clearing the ARP cache on the device (192.168.1.5) didn' t help. Something I already thougth of and tried before, btw :-) I' ve just spoken to out contact person @Fortinet and he is thinking towards Hardware Revisions. According to a document it should work on a FG200A290xxxxxxx mine is a FG200A390xxxxxxx, a brand new one. He' s investigating the issue as we speak. Also, i' m running MR3.0 I can' t find any document that says this will work on MR4.0 Until I' m really really convinced I need to go to MR4.0, MR3.0 is staying on there.
    UkWizard
    UkWizard
    New Member
    May 21, 2007
    All i know is that you need ' Revision 2' , of that hardware, for this feature. Not sure how to find the revision of the hardware, but check the label underneath in case it states it. judging from the sniffing error you got, it definately looks like it cannot see the physical interfaces, doesnt it. so it could be the revision. Is the unit new? From the CLI, if you list the interfaces, i presume it does see the internal ones? Also try sniffing using " any" interfaces instead, should be; diag sniff pa any icmp
    A
    Anonymous_UserAuthor
    Contributor
    May 21, 2007
    According to the Fortinet guy I have a ' revision2' the manufacaturing date on the appliance states 2007.02 so it' s a brand new one. The document the Fortinet guy spoke about, I reckon they are the release notes of some Firmware, stated that it' s supported on Revision2 appliance with serial numbers starting with FG200A290xxxxxxx. Mine starts with FG200A390xxxxxxx. This could perhaps mean it' s another revision. And maybe, just maybe, this isn' t working because of that. I' m trying MR4 this afternoon. Just to make sure it' s not firmware related.
    A
    Anonymous_UserAuthor
    Contributor
    May 21, 2007
    I received ' FGT_200A-v300-build0480-FORTINET.out' as a new firmware and that solved the problem.
    UkWizard
    UkWizard
    New Member
    May 21, 2007
    Good stuff, worth noting.
    Terms & ConditionsAccessibility statement