3

I'm not quite certain how to achieve the equivalent of ip directed broadcast with a FortiGate. In this case a FortiGate 60E with FortiOS 5.6.7. So I started to dig a little.

QUESTION: Can anyone confirm that, on a FortiGate, set broadcast-forward enable on the egress interface does actually forward a directed broadcast packet to the given subnet as broadcast (as in: DstMAC ff:ff:ff:ff:ff:ff) out of that interface? Suitable firewall policies assumed to be in place, of course.

EDIT: That part of the question is answered: No, set broadcast-forward enable on the egress interface does not have this desired effect.

Sideline Question: Is there another way to achieve this on a FortiGate?

EDIT 2020-07-21: Yes, it is possible. See "ADDON-2" below. It is based on Lukas' answer (see below).

Please note: I am perfectly familiar with ip directed-broacast <someACL> on Cisco routing gear, and I've successfully deployed WoL support many times with that.

Also note: I'm also not trying to make something like a broadcast-helper or WoL relay work on a FortiGate interface facing the WoL Magic Packet sending host. That host knows the remote subnet's directed broadcast address and sends to it.

I keep finding hints (such as next door on serverfault) that set broadcast-forward enable were to add support to have directed broadcasts forwarded as broadcasts in the attached subnet.

The documentation (or its equivalent for FortiOS 5.6) quoted with that has this to say:

ARP: by default, ARP broadcasts and ARP reply packets are flooded/forwarded on all ports or VLANs belonging to the same forwarding domain, without the need of firewall policies between the ports. This default behavior is necessary to allow the population of the FDB and allow further firewall policy lookup (see section Transparent mode Firewall processing for more details). This option is configurable at the interface settings level with the parameter arpforward (enabled by default).

Non-ARP: To forward non-ARP broadcasts, the following CLI command is used:

config system interface

edit "port2"

set broadcast-forward enable

next
end

BUT this quote is from the Networking in Transparent Mode section of the documentation (see --> Packet Forwarding --> Broadcast, Multicast, Unicast Forwarding), and we're not running transparent mode, here.

AND I do get the impression that set broadcast-forward enable is more an ingress thing than something for egress. The "best answer" in this thread on the Fortinet community kind of confirms this gut feeling.

I have also read the FortiNet KB article, which is also being quoted and referenced elsewhere, but ... static ARP entries? Really? We have dozens of clients at that site! (Well, I could still add a static ARP entry for the directed broadcast address with ff:ff:ff:ff:ff:ff, but that seems somewhat wrong.)

Thanks for your answers, comments and pointers.


[ADDON-1]:

As suggested in zac67's answer, I tried with a multicast address, multicast policy, plus a narrow unicast policy (allowing source to directed-broadcast). None had the desired effect.

Also: set broadcast-forward enable on the egress interface has no effect. Packets get dropped upon ingress because of an ip forwarding check failure.

id=20085 trace_id=35 func=fw_local_in_handler line=402 msg="iprope_in_check() check failed on policy 0, drop"

Interestingly this happens despite the fact that the firewall does have a entry in the routing table mapping 192.168.10.255/32 to the correct egress interface.

RemoteFirewall # diag ip route list | grep 192.168.10
tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.10.0/32 pref=192.168.10.1 gwy=0.0.0.0 dev=8(internal1)
tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.10.1/32 pref=192.168.10.1 gwy=0.0.0.0 dev=8(internal1)
tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.10.255/32 pref=192.168.10.1 gwy=0.0.0.0 dev=8(internal1)
tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.10.0/24 pref=192.168.10.1 gwy=0.0.0.0 dev=8(internal1)

It is only with set broadcast-forward enable on the ingress interface (sic! Just don't get me started on the implications of this!) of the last hop Fortigate that I see a change in behaviour.

Please note: My tests were done with ICMP. Near the WoL sender, I only have access to systems that can send ICMP, not udp/9. Should be of no relevance, here.

filters=[host 192.168.115.1]
3.881184 WAN1 in 192.168.115.1 -> 192.168.10.255: icmp: echo request
3.881469 internal1 out 192.168.115.1 -> 192.168.10.255: icmp: echo request
3.882015 internal1 in 192.168.10.3 -> 192.168.115.1: icmp: echo reply
3.882016 internal1 in 192.168.10.2 -> 192.168.115.1: icmp: echo reply
3.882033 internal1 in 192.168.10.4 -> 192.168.115.1: icmp: echo reply
4.896689 WAN1 in 192.168.115.1 -> 192.168.10.255: icmp: echo request
4.896771 internal1 out 192.168.115.1 -> 192.168.10.255: icmp: echo request
4.897309 internal1 in 192.168.10.2 -> 192.168.115.1: icmp: echo reply
4.897325 internal1 in 192.168.10.3 -> 192.168.115.1: icmp: echo reply
4.899076 internal1 in 192.168.10.4 -> 192.168.115.1: icmp: echo reply
    

So at least, something is happening. But these packets are (at layer 2) not real broadcasts, but they're being sent to DstMac 00:00:00:00:00:00 (where I'd expect ff:ff:ff:ff:ff:ff)

filters=[host 192.168.115.1]
4.492989 WAN1 in 192.168.115.1 -> 192.168.10.255: icmp: echo request
0x0000   0000 0000 0001 0000 0000 0000 0800 4500        ..............E.
0x0010   0054 2614 0000 4001 5544 c0a8 7301 c0a8        .T&...@.UD..s...
0x0020   0aff 0800 8984 5700 0000 13a2 c25c 0000        ......W......\..
0x0030   0000 3a7c 0700 0000 0000 0000 0000 0000        ..:|............
0x0040   0000 0000 0000 0000 0000 0000 0000 0000        ................
0x0050   0000 0000 0000 0000 0000 0000 0000 0000        ................
0x0060   0000                                           ..

4.493277 internal1 out 192.168.115.1 -> 192.168.10.255: icmp: echo request
0x0000   0000 0000 0000 0009 0f09 0b01 0800 4500        ..............E.
0x0010   0054 2614 0000 3f01 5644 c0a8 7301 c0a8        .T&...?.VD..s...
0x0020   0aff 0800 8984 5700 0000 13a2 c25c 0000        ......W......\..
0x0030   0000 3a7c 0700 0000 0000 0000 0000 0000        ..:|............
0x0040   0000 0000 0000 0000 0000 0000 0000 0000        ................
0x0050   0000 0000 0000 0000 0000 0000 0000 0000        ................
0x0060   0000                                           ..

This behaviour is seen with or without any of the multicast config bits in place, and with or without the narrow unicast firewall policy.

Adding set broadcast-forward enable to the egress interface does not change the DstMAC address being used in the egress packet. Still, some systems on the local subnet seem to react to DstMAC 00:00:00:00:00:00 and send their ping replies. these of course are out-of-state to the firewall and get dropped - no harm in that.

I'll have the server team try WoL with the given configuration - if that won't work, we'll try setting a static ARP entry mapping 192.168.10.255 to ff:ff:ff:ff:ff:ff

[/ADDON-1]:


[ADDON-2 2020-07-21]:

Yes, it took a while for the Systems Managament people to get back to the topic and eventually find some time to send some WoL Magic Packets down the WAN.

Testing was done on a Fortigate 100E with FortiOS 6.0.8.

See Lukas' answer below for a config example. No form of broadcast-forward enable was needed. I am aware that zac67's answer says the same, but includes broadcast-forward enable.

This is what the directed broadcast looked like when it left the FG100 into the given LAN/Subnet. You'll note the proper broadcast destination address (ffff.ffff.ffff).

87.273480 port7 -- 192.168.35.9.54525 -> 192.168.37.255.7: udp 102
0x0000   ffff ffff ffff 0009 0f09 2012 0800 4500        ..............E.
0x0010   0082 185b 0000 7e11 59b7 c0a8 2309 c0a8        ...[..~.Y...#...
0x0020   25ff d4fd 0007 006e 5494 ffff ffff ffff        %......nT.......
0x0030   f8b4 6a25 9dd7 f8b4 6a25 9dd7 f8b4 6a25        ..j%....j%....j%
0x0040   9dd7 f8b4 6a25 9dd7 f8b4 6a25 9dd7 f8b4        ....j%....j%....
0x0050   6a25 9dd7 f8b4 6a25 9dd7 f8b4 6a25 9dd7        j%....j%....j%..
0x0060   f8b4 6a25 9dd7 f8b4 6a25 9dd7 f8b4 6a25        ..j%....j%....j%
0x0070   9dd7 f8b4 6a25 9dd7 f8b4 6a25 9dd7 f8b4        ....j%....j%....
0x0080   6a25 9dd7 f8b4 6a25 9dd7 f8b4 6a25 9dd7        j%....j%....j%..

Hint: the FG100E showed similar behaviour as the FG60E from earlier tests.

With diag sniffer packet any <someFilterString>, the destination MAC was shown as 0000.0000.0000, but diag sniffer packet port7 <someFilterString> showed ffff.ffff.ffff. That's not quite what one would expect, and extends troubleshooting unnecessarily.

[/ADDON-2]:


  • It would seem that the interface with a configured address and mask would behave like any other network host and understand that the broadcast IPv4 address is sent to the layer-2 broadcast address. I do not have a Fortigate, but checking several different hosts and network devices here reveals that the ARP table for an interface has an entry for the IPv4 broadcast address to the layer-2 broadcast address. – Ron Maupin Apr 25 '19 at 17:13
  • @RonMaupin I could not find an ARP entry for the directed-broadcast address, but indeed, for 255.255.255.255, we find index=8 ifname=internal1 255.255.255.255 ff:ff:ff:ff:ff:ff state=00000040 ... – Marc 'netztier' Luethi Apr 26 '19 at 8:15
  • another interesting fact: when pinging 192.168.10.255 from the FortiGate unit itself (exec ping 192.168.1.255), the packets are leaving the box with DstMAc address ff:ff:ff:ff:ff:ff . – Marc 'netztier' Luethi May 6 '19 at 13:40
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer. – Ron Maupin Dec 15 '19 at 2:16
2

FortiGates seem to behave differently under FortiOS v6.0.6 compared to v5.6.11. So you might want to make sure you upgrade your FortiGate first, if that is a feasible option for you. I don't know when exactly/with which FortiOS version the behavior changed. But I am pretty happy with v6.0.6 so far, also when it comes to several UTM features and deep inspection.

I just recently upgraded to v6.0.6 and implemented Zac67's suggestion. The only thing I configured is a multicast policy. A static ARP entry and "set broadcast-forward enable" is not needed, neither on ingress interface nor on egress interface.

By the way: my sender ("SCCM") is multiple hops away, it is not connected to the same firewall as the client subnet.

config firewall address
    edit "SCCM"
        set associated-interface "Z-WAN01"
        set subnet 192.168.10.20 255.255.255.255
    next
end

config firewall multicast-address
    edit "CLIENTNET_BROADCAST"
        set type broadcastmask
        set comment "BROADCAST ADDRESS OF WIRED CLIENT NETWORK USED FOR WAKE ON LAN"
        set color 9
        set subnet 10.0.0.255 255.255.255.255
    next
end

config firewall multicast-policy
    edit 1
        set logtraffic enable
        set srcintf "Z-WAN01"
        set dstintf "Z-INSIDE01"
        set srcaddr "SCCM"
        set dstaddr "CLIENTNET_BROADCAST"
        set protocol 17
        set start-port 9
        set end-port 9
    next
end

Hope this helps!

| improve this answer | |
  • Thanks Lukas for that answer. I'll see if I can get the upgrade done on the given customer site and I'll report back. – Marc 'netztier' Luethi Oct 7 '19 at 7:36
  • 1
    I was able to implement this today on a FG 60E upgraded to 6.0.6. Testing was only possible with ICMP (didn't have access to the WoL sender nor found anyone who had time). Eventually, using diag sniffer packet <egressif> ... instead of diag sniffer packet any ...eventually helped to show that the packets were actually leaving the fortigate with ff:ff:ff:ff:ff:ffas the destination address. With the any keyword, dstMAC address was always shown as 00:00:00:00:00:00. I'll add a more detailed answer once we have confirmation that WoL actually works. – Marc 'netztier' Luethi Oct 26 '19 at 21:43
2

In a way, you have given all the correct answers to your questions. Just to confirm:

1- The option set broadcast-forward enable is only effective for FGTs in Transparent Mode, not Routing/NAT mode. This fact is confirmed in the FTNT forum post by emnoc and the OP.

2- the KB article you cite is a working solution if you want to send a broadcast across a routing FGT. Note that you should use an unused IP address in the config (.19 in the example whereas .18 is the real address of the destination host).

If you want to send directed broadcasts to multiple/several hosts you will have to create one IP/broadcast MAC pair for each.

ede_pfau

| improve this answer | |
  • See "Addon-1" in the question: set broadcast-forward enable does have an effect in Routed/NAT mode - just not the desired one, and only if applied to the "wrong" interface. – Marc 'netztier' Luethi Apr 26 '19 at 7:30
  • cool digging! keep posting your results. – user1016274 Apr 27 '19 at 12:01
2

I've set set broadcast-forward enable on both, the ingress and the egress interfaces (over VPN).

And I've added a multicast address:

config firewall multicast-address
    edit "directed_broadcast"
        set type broadcastmask
        set comment "WoL"
        set associated-interface "internal"
        set subnet 172.16.15.255 255.255.255.255
    next
end

and a multicast policy:

config firewall multicast-policy
    edit 2
        set logtraffic enable
        set srcintf "SOURCE"
        set dstintf "DESTINATION"
        set srcaddr "all"
        set dstaddr "directed_broadcast"
        set protocol 17
        set start-port 0
        set end-port 255
    next
end

I also needed an explicit policy permitting the directed broadcast - in addition to 172.16.15.0/24 I had to add 172.16.15.255 as destination (did it back in 4.x or 5.4).

I'm not really sure if everything is (still) required but that did the trick.

Before, we used the 'static ARP trick' where you reserve a normal IP address and on the router you add a static ARP entry to map that IP to ff:ff:ff:ff:ff:ff. The directed broadcast has the advantage that normal LANdesk WoL works with it.

| improve this answer | |
  • Thanks for that. I'll give that a try, too. Does that add up to three config items? The multicast address, the multicast policy AND an explicit (unicast) policy? – Marc 'netztier' Luethi Apr 25 '19 at 19:07
  • @Marc'netztier'Luethi Actually four - but the set broadcast-forward enable might not really be required. Anyway, Fortinet should document this better... – Zac67 Apr 25 '19 at 19:13
  • So far, setting a multicast policy had no effect whatsoever. Also the explicit additional unicast policy allowing the to-be-broadcasted traffic was without effect. The packet gets dropped upon ingress to the last hop router/firewall. set broadcast-forward enable on the egress interface made no difference, either. However, I can get the packet to be forwarded by setting broadcast-forward enable on the ingress interface (see upcoming edit of the question) - and to some extent that's all that is needed (suitable unicast policy required, of course.) – Marc 'netztier' Luethi Apr 26 '19 at 6:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.