Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
mzachar
New Contributor II

60D ARP issue?

Hello,

I have FGT 60D (5.4.1) in FW only role. No other features enabled. Brief config is as follows:

[ul]
  • vswitch1 (software switch) = internal1, internal2 in LAN role.
  • DHCP Server enabled on it.
  • Device Detection enabled.
  • Active Scanning disabled.
  • Additionally, internal1 (phy-port) has 2 VLANs configured, each with DHCP Server enabled, similar as above.
  • Only one FW policy defined, allowing all from Internal to WAN1.[/ul]

    To internal1 I have L3 switch enabled. There are no ACLs, no L2 filtering enabled. No traffic alternations, everything takes place in flat native VLAN (1) for internal1. Those 2 additional VLANs are not yet deployed.

     

    Now, when I connect through LAN port of switch I get ip from DHCP server (FGT). ARP table on PC is updated with FGT ip/mac.

    When I disconnect from LAN and connect through AP (not Forti, no special config, one flat VLAN, same as when on LAN connection), I get ip from DHCP server (FGT) but there are no ARP replies from FGT in packet capture. PC keeps sending ARP requests for FGT MAC, but without reply from FGT and ARP table on PC is not updated with FGT ip/mac. No communication is possible. Connecting back to LAN fixes ARP.

     

    Is there any default policy that may affect this behavior? Does FGT somehow detects this is same host but with different MACs (LAN & WLAN) and blocks ARP replies?

     

     

     

  • 6 REPLIES 6
    Dave_Hall
    Honored Contributor

    On fortinet AP equipment the wifi controller has options for suppressing various broadcast messages, including ARP.  Perhaps you need to check to see if this 3rd party AP hardware has similar options. 

     

    NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C

    NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C
    mzachar
    New Contributor II

    Thanks Dave for your reply, but now I am sure its FGT causing ARP "problem".

     

    To simplify things my network topology is as follows:

     

    FGT:internal1 <-----> Switch <-----> AP1 "ssid:RED"

    FGT:internal2 <-----> AP2 "ssid:BLUE"

     

    FGT reboot.

    Connecting via AP1 ("RED") or Switch is OK. As long as I connect through Internal1 to FGT (doesn't matter if through AP1 or Switch) I get ip from DHCP server and ARP requests from PC are answered by FGT. Communication is OK.

    Now, when at this point I connect to AP2 ("BLUE") or directly (via LAN) to Internal2, I get DHCP from FGT but ARP request from PC are not answered by FGT.

     

    Now, rebootin FGT again and doing symmetrical thing, connecting to AP2 or directly to Internal2 just after FGT reboot, everything is OK. I can switch between AP2 or Internal2 access without issues. But trying to connect to AP1 or via Switch which are connected to Internal1, results in ARP issue (DHCP is ok, just ARPs are not answered by FGT).

     

    So, there must be some feature at FGT that prevents ARP between Internal1 and Internal2, despite the fact, these ports serve the same network (same native VLAN), they are part of software switch.

     

    Is this an issue? Or is this expected by desing? How change this behavior to have a "single" network served by both physical ports?

     

    This is my port config:

    config system interface     edit "internal1"         set vdom "root"         set type physical         set alias "phy-port1"         set role lan         set snmp-index 7     next     edit "internal2"         set vdom "root"         set type physical         set alias "phy-port2"         set role lan         set snmp-index 8     next     edit "vswitch_1"         set vdom "root"         set ip 192.168.0.1 255.255.255.0         set allowaccess ping https ssh         set type switch         set device-identification enable         set role lan         set snmp-index 9

        next

        edit "vlan_10"         set vdom "root"         set ip 192.168.10.1 255.255.255.0         set allowaccess ping https ssh         set role lan         set snmp-index 10         set interface "internal1"         set vlanid 10     next     edit "vlan_20"         set vdom "root"         set ip 192.168.20.1 255.255.255.0         set allowaccess ping https ssh         set role lan         set snmp-index 11         set interface "internal1"         set vlanid 20     next

    emnoc
    Esteemed Contributor III

    Mac Address  tables show sow  mac.addr flap but  does the deviec interface when directly connecting or WLAN have a different ether.address so I would check that and do a  diag sniffer to see ARP requests arriving from   WLAN. If you have no  ARP request than the issues in the wifi overlay. The FGT could care less  if it's wired or wireless clients imho

     

    Ken Felix

     

    PCNSE 

    NSE 

    StrongSwan  

    PCNSE NSE StrongSwan
    mzachar
    New Contributor II

    Hi emnoc,

     

    I will rephrase my situation for clarity.

     

    I can connect to LAN or WLAN (back and forth) as long as I stay connected to service provided by the same port on FGT, either Internal1 OR Internal2. All is OK, DHCP & ARP work OK.

     

    But in scenario when PC was previously connected to LAN or WLAN thorugh Internal1 port, and there was no FGT reboot before trying to connect to LAN or WLAN serviced by Internal2 port on FGT, DHCP is OK, but ARP replies do not come from FGT. I need to reboot FGT to be able to use LAN or WLAN serviced by Internal2 port, but again when I move to LAN or WLAN serviced by Internal1 port (without FGT reboot in between), again DHCP is ok but ARP problem arises.

     

    WLAN overlay is not a problem. I have done traffic capture, ARP requests from PC are visible on Switch uplink port to FGT for LAN or WLAN connected PC.

     

    But I am willing to do diag sniff on FGT itself if somebody will point me to a guide, how to configure it, as I am FGT newbie.

    EDIT: found nice explanation of diag sniffer tool. Will update this thread later.

    https://kb.fortinet.com/k...nk.do?externalID=11186

     

    mzachar
    New Contributor II

    SOLVED: It was a bug in FortiOS 5.4.1 (and 5.4.3, also 5.4.5)

     

    After upgrade to FortiOS v5.6.2 build1486 (GA) problem disappeared. No changes to Switch or APs config were made.

    Upgrades to 5.4.3 build 1111 and 5.4.5 build 1138 did not solve this problem.

     

    umutkacar

    Hello mzachar,

     

    Did you find a solution for this?

    Labels
    Top Kudoed Authors