Skip to main content
mzachar
mzachar
New Member
April 21, 2019
Question

60D ARP issue?

  • April 21, 2019
  • 1 reply
  • 10841 views

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?

     

     

     

    • 1 reply

    Dave_Hall
    Dave_Hall
    New Member
    April 22, 2019

    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. 

     

    mzachar
    mzacharAuthor
    New Member
    April 23, 2019

    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
    emnoc
    New Member
    April 23, 2019

    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

     

    Terms & ConditionsAccessibility statement