Recently I got a call from my buddy. He told me that he’d like to be able to remotely wake computers in his network via ssl vpn. I asked from which vendor he has that ssl gateway or firewall where he terminates ssl vpn. Then I added that if it’s not Juniper, I can’t help :P.
He said that it’s Fortinet’s Fortigate. ‘Ok, I’ll have a look into it’, I said. And I did. Of course quite some time have passed since I had dealt with wake on lan feature, but I did remember that Juniper has it’s targeted broadcasting. To put it simply, this feature allows the device to forward broadcast packets to the specific subnet originated from a different subnet :). This is done by a Routing Engine or, generally speaking, the ‘control plane’ of the device. For Juniper devices, handling of the wol magic packet in L3 environment is described here.
See here to find out more about targeted broadcast (please, read the notes).
Ok, this is rather simple in case you have common type interfaces, with subnets and ip addresses. But, what about the situation where you have unnumbered interface like SSL interface on Fortigate? You can’t just send the broadcast packet and hope that the device will actually do something with it. Quick google search and voila:
http://kb.fortinet.com/kb/viewContent.do?externalId=FD30104
In my opinion, Fortinet has more elegant and more useful approach to that problem. The only thing you need to do (besides configuring the SSL settings and all the policies needed) is to create a static ARP entry with mac address of all the f’s like in that KB above. Note that this static ARP has an IP address that isn’t used in the destination network – you have to sacrifice one. Also, since Fortinet documentation can be misleading, you don’t need the static ARP of the host that is being waked. This static ARP in the KB is just for the information purposes.
The last thing you’ll have to remember and check before you deploy such feature in your network is to read the manual, as well as all the options of your WOL software.
In case of the Fortinet’s example, we’re sending the “magic packet” to the IP address of that static arp, but with the mac address of the actual endpoint that we want to wake. But in this (linux wakeonlan utility) example, the mac notation is reversed.
For my tests I’ve used the wakemeonlan utility – https://www.nirsoft.net/utils/wake_on_lan.html where you have to do two steps:
1. Configure the entry of the destination host with an ip address of a static ARP and MAC address of the actual host.
2. Set the option to send the wol packet to the destination address of the device instead of a broadcast address.
Below you can see my configuration on Fortigate and the utility itself.
FORTIGATE (arp-table) # show
config system arp-table
edit 1
set interface “TEST_NETWORK”
set ip 10.10.53.253
set mac ff:ff:ff:ff:ff:ff
next
end
And here are the test results:
FORTIGATE # execute ping 10.10.53.69
PING 10.10.53.69 (10.10.53.69): 56 data bytes— 10.10.53.69 ping statistics —
5 packets transmitted, 0 packets received, 100% packet lossFORTIGATE # execute ping 10.10.53.80
PING 10.10.53.80 (10.10.53.80): 56 data bytes— 10.10.53.80 ping statistics —
5 packets transmitted, 0 packets received, 100% packet lossFORTIGATE # diagnose sniffer packet TEST_NETWORK “dst 10.10.53.253” 4
interfaces=[TEST_NETWORK]
filters=[dst 10.10.53.253]
4.363497 TEST_NETWORK — 10.212.134.2.65499 -> 10.10.53.253.4343: udp 102
4.386330 TEST_NETWORK — 10.212.134.2.65500 -> 10.10.53.253.4343: udp 102
4.397172 TEST_NETWORK — 10.212.134.2.65501 -> 10.10.53.253.4343: udp 102
4.408230 TEST_NETWORK — 10.212.134.2.65502 -> 10.10.53.253.4343: udp 102
8.660241 TEST_NETWORK — 10.212.134.2.58531 -> 10.10.53.253.40000: udp 1025 packets received by filter
0 packets dropped by kernelFORTIGATE # execute ping 10.10.53.69
PING 10.10.53.69 (10.10.53.69): 56 data bytes
64 bytes from 10.10.53.69: icmp_seq=0 ttl=128 time=0.3 ms
64 bytes from 10.10.53.69: icmp_seq=1 ttl=128 time=0.2 ms
64 bytes from 10.10.53.69: icmp_seq=2 ttl=128 time=0.3 ms— 10.10.53.69 ping statistics —
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.3 msFORTIGATE # execute ping 10.10.53.80
PING 10.10.53.80 (10.10.53.80): 56 data bytes— 10.10.53.80 ping statistics —
5 packets transmitted, 0 packets received, 100% packet lossFORTIGATE # execute ping 10.10.53.80
PING 10.10.53.80 (10.10.53.80): 56 data bytes— 10.10.53.80 ping statistics —
1 packets transmitted, 0 packets received, 100% packet lossFORTIGATE # execute ping 10.10.53.80
PING 10.10.53.80 (10.10.53.80): 56 data bytes
64 bytes from 10.10.53.80: icmp_seq=0 ttl=128 time=0.5 ms
64 bytes from 10.10.53.80: icmp_seq=1 ttl=128 time=0.5 ms— 10.10.53.80 ping statistics —
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.5/0.5/0.5 ms
As far as I know the Palo Alto firewalls use the same technique as the Fortigates.