VDOM acting as a transparent Wake-On-LAN proxy

[kallbrandt]

Hello,

A customer case:

Customer has approx. 10 different client-VLANS, > 2000 windows machines, and wants to be able to start them on demand to perform updates, re-installs etc. Figures... SCCM 2012r2 Configurations Manager is used as the client deployment solution. The SCCM-server is located on a server-VLAN, separated from the users. It is a production environment, and the suggested solutions and guides availible online are suggesting UDP relay, hard-coding a static ARP entry etc.  The server and the user VLANS are handled in different routers, adding to the complexity. Customer more or less got stuck with this issue, since most solutions looked either sketchy security-wise at best, or overly complicated. Solution: Use a Fortigate with a transparent VDOM to silently "snoop" for the "Magic Packet" on layer 2, and then forward it directly to the desired VLANS without changing or interfering with anything in the routed/switched path. Setup is tested on FortiOS 5.4.3 (51E) and 5.2.10 (100D), all switchports used should be configured to only send 802.1q-tagged packets. If a PVID/default untagged VLAN is used, it should be a disabled/dummy VLAN that can't forward any frames in order to avoid any leakage. Keep it clean. Create a transparent VDOM containing two (or more) physical interfaces. Physical interface 1 is hosting the server-VLAN that the WOL-sending server resides within. Physical interface 2 is for the destination VLANS that you want to forward the WOL-broadcast frame to. Create the VLAN-interfaces. Turn off ALL the forwarding settings below on ALL interfaces, both physical and VLAN (better safe then sorry...): arpforward          : disable broadcast-forward   : disable l2forward           : disable icmp-redirect       : disable vlanforward         : disable stpforward          : disable All those settings should be disabled, as you want your L2-interfaces to be dead silent in this setup. Otherwise you will create a mess, trust me... Use wireshark or consult the documentation to find out what UDP port/s your WOL-sending server is using. For SCCM 2012r2, the system itself uses UDP port 9, but the manual Wake-On-Lan "right-click tool" is actually using UDP port 12287. The SCCM scheduler and the right-click-tools are using different PowerShell scripts for the WOL functionality. If you want to change the ports in the scripts so that they use the same port - Go ahead and do it.

Create Services for all the ports that are used. (Any destination port is fine btw, my pfSense firewall at home did send the Wol-packet to UDP-port 40000. The destination computer doesn't care.) Create address objects for the WOL-sending server, and the ethernet broadcast address 255.255.255.255/32 Create a firewall policy FROM the server VLAN-interface + server address TO the destination VLAN-interfaces + 255.255.255.255/32 as destination address.

Add the service/UDP ports that are used. Done. It works just fine, and packet captures on the server/destination VLANS doesn't show any leakage between the VLANs other then the WOL broadcast, IF you did everything right that is...

You will notice that the packet counters in the firewall rule/s doesn't show anything even if you enable full logging.

That's because you are forwarding ethernet broadcast frames, not IP-packets.

Hopefully someone else can benefit from this.

Enjoy.

[Alby23]

Thanks a lot! This is a really interesting and alternative way for using FG :D

[kallbrandt]

A WORD OF ADVICE:

In my lab and my initial deployment of the setup above, I didn't see anything odd.

But... When deployed fully (+30 VLANS on recieving end), I could see an alarming increase in CPU usage in the router handling most of the VLANS. It wasn't noticeble until we deployed all of them.

It is fixable however.

To avoid all sorts of snafus, you must drop egress traffic on the switchport connected to the egress port on the Fortigate. No traffic whatsoever should be allowed outwards from any of the VLANS in the setup, just incoming traffic from the Fortigate. Then it really doesn't matter that the Fortigate makes one big broadcast domain of all the VLANS. Disabling all forwarding of arp/broadcast/icmp in the Fortigate only takes you so far it seems.

But, this homebrewed "multicasted" bridging design lives on. And the magic packet pours out where it should.

;)