iprope_in_check failed, drop

[FrankCQI]

Hi, we have a fortigate 60D. I have an access point who must report to a wireless controller on another subnet going through the fortigate. Route are OK as other devices can route traffic just fine between the 2 subnet. It seems the broadcast from the access point to discover the wireless controller are blocked... Here is the result of the debug trace : id=13 trace_id=200 msg=" vd-root received a packet(proto=17, 172.25.18.206:38212->255.255.255.255:38212) from internal." id=13 trace_id=200 msg=" allocate a new session-00000663" id=13 trace_id=200 msg=" iprope_in_check() check failed, drop" Why is it blocked? How Can I allow that traffic? Both subnet are reachable via the " internal" interface of the fortigate.

[FrankCQI]

My controller and access point are not Fortinet product, they are HP MSM products. I don' t think your solution would work. I already ran the " set broadcast-forward enable" command, and traffic is still blocked. Any other idea?

[ede_pfau]

DHCP options are part of the protocol standard (RFC) meaning they are vendor independent. I' d give it a try.

[Dave_Hall]

Looking at one of the HP MSM controller manuals, those APs can locate the controller through UDP broadcast (local subnet only), DHCP, or DNS. You may want to try one of the alternate methods (page 188 through 193 of linked pdf above).

[FrankCQI]

We already have entry in the DNS to have the AP find the controller on a different subnet.

[FrankCQI]

I added the " set option1 138 ' HEXADRESS' " in the dhcp config of my fortigate, still no luck....

[Dave_Hall]

I added the " set option1 138 ' HEXADRESS' " in the dhcp config of my fortigate, still no luck....

As far I am aware, the HP MSM controllers do not follow the capwap standard. That PDF manual I linked to earlier indicates something about setting up a Colubris vendor class identifier and/or Colubris-specific options (43) (see page 646 to 655). I never played around with vendor classes, but on the fgt, you need to configure them on CLI (under config system dhcp server section).

[FrankCQI]

Yes I did set it up under CLI, after reviewing your post I change it to options 43... Still no luck!

[Dave_Hall]

I am thinking the AP is expecting something more than just the hex value of the controller' s IP address. You may have to enter the value for option 43 as... 01 08 " 4-byte hex value of controller IP address" x 2. (see pic). edit: don' t know if hex 0A is needed or not or if the fgt will pass the length of the option string itself. Personally, if you only have a handful of APs or less, I may consider a short-term solution and just manually program the controller' s IP address into each AP; later if there is time try getting the DHCP option working.

[emnoc]

You might have a better solution. If you have an existing dhcp server for the WifiAP or if the wlan-controller is the dhcp ( even better ) than why don' t you enable dhcp-relay on the interface that attaches to the HP AP and relay the dhcp-discover to the dhcp-server? I do and recommend this when I work with phone-gear and want a central dhcp management. It would also avoid having to figure out the dhcp-server options and hex conversion, blah blah blah..... It will only require 2 cmds on the fortigate btw config t edit " your interface name" set dhcp-relay-service enable set dhcp-relay-ip x.x.x.x <-----your existing AP dhcp server end and then defining a scope on the dhcp-server for this network build your policy for the AP ,etc......

[Dave_Hall]

This page gives a nice tutorial on how to set up option 43 on a fgt device.