Wake on LAN - Can wake from GUI but not from outside

JohnnyBeGood

Hi all,

I'm running v2.0-RC3 and I have setup port forward from 55940 to port 9 and all works fine when I try to wake up using my cell phone.
Problem is that when I leave computer in standby over night and try in the morning I can't wake it up.
Using Services > Wake On LAN it wakes it up right away. Computer is running Win7 with static IP.

Any suggestions?

Thanks in advance!

NOYB

ARP age.

Where is port 9 being forwarded to?
Unless it is a broadcast, it won’t work once the target machine has been aged out of the ARP table. And since it is not on it won’t respond to any ARPs.

Is it possible to configure forward target to be 255.255.255.255? That way the WoL packet will be seen by all machines. (assuming WoL Magic Packet is being used).

stompro

It isn't possible to port forward to broadcast addresses, the OS blocks the attempt for security reasons. I tried to get this working several years ago, but ran into that wall. You need to either use the web interface, (which can be scripted with curl,wget, etc) or ssh in and use the wakeonlan command(also can be scripted), or install some sort of proxy that will handle rebroadcasting the wake on lan packets.

I went with the curl + webgui method. You can create a user that only has access to the WOL page, to reduce the security risk of having your admin password in a script.

Josh

NOYB

Well if pfSense system cannot forword to broadcast address then maybe something like this is in order.

http://www.dslreports.com/forum/r22499456-Request-for-an-Odd-Device-WoL-
http://www.dslreports.com/forum/r22505430-
http://www.dslreports.com/forum/r22512767-Request-for-an-Odd-Device-WoL-
http://www.dslreports.com/forum/r22532253-Request-for-an-Odd-Device-WoL-

stompro

You might want to summarize what your point is, I tried skimming through the first link be couldn't guess what tactic you thought would be useful. Setting a machines MAC to FF:FF:FF:FF:FF:FF is entertaining, but not really a great strategy.
Josh

NOYB

Setting a machine's MAC to all FF's is the point. So you got it. Then forward WoL to that machine will result in a broadcast. It works, but would be better to do it all within pfSense rather than having another piece of hardware though.

The last 3 links are methods of configuring a couple of old 'routers' with all FF MAC to turn them in to sort of a "broadcast agent" that could be used with WoL.

A static ARP entry may work too. That's what we used to do with the Actiontec.
Will need a script to run at start up for the ARP entry to survive a reboot though.

arp -s 192.168.1.254 ff:ff:ff:ff:ff:ff
arp -an to view

Add static host or DNS entry if name resolution desired.
ff:ff:ff:ff:ff:ff 192.168.1.254 Broadcast

JohnnyBeGood

@NOYB:

ARP age.

Where is port 9 being forwarded to?
Unless it is a broadcast, it won’t work once the target machine has been aged out of the ARP table. And since it is not on it won’t respond to any ARPs.

Is it possible to configure forward target to be 255.255.255.255? That way the WoL packet will be seen by all machines. (assuming WoL Magic Packet is being used).

Port 9 is forwarded to a computer with static IP.

There's another twist I've tried this morning. I have 2nd computer that is HTPC (Win 7 Pro) and when I try to wake it up with cell phone it worked!
Tried same with desktop and it does not work :(
Used pfSense GUI and it woke it up right away.
I went thru and compered all settings that are on the NIC and everything pretty much matches. One difference is that HTPC has Gigabyte GA-H67A-UD3H-B3 MB and desktop has Asus Sabertooth x58 both are using built in NIC.

wallabybob

WOL sometimes needs to be enabled in BIOS.

NOYB

JBG,

Before trying to wake them with the cell phone, go to Diagnostics - ARP Table. Is MAC and IP listed for machine? If not, that is why it won't wake up. It has been aged out of the ARP table. So that being the case the WoL 'Magic Packet' must be forwarded as a broadcast rather than to a specific machine. Try this…

Drop to a shell ( option 8 )
arp -s 192.168.1.254 ff:ff:ff:ff:ff:ff
arp -an (should see above entry)

Configure Firewall NAT Rule to forward your cell phone WoL to 192.168.1.254

Obviously replace above ip address with one appropriate for your network. Doesn't really matter what it is so long as it is valid for your subnet, unused and ARP table has it listed with MAC of all FF's.

Now try waking with cell phone.

JohnnyBeGood

@NOYB:

JBG,

Before trying to wake them with the cell phone, go to Diagnostics - ARP Table. Is MAC and IP listed for machine? If not, that is why it won't wake up. It has been aged out of the ARP table. So that being the case the WoL 'Magic Packet' must be forwarded as a broadcast rather than to a specific machine. Try this…

Drop to a shell ( option 8 )
arp -s 192.168.1.254 ff:ff:ff:ff:ff:ff
arp -an (should see above entry)

Configure Firewall NAT Rule to forward your cell phone WoL to 192.168.1.254

Obviously replace above ip address with one appropriate for your network. Doesn't really matter what it is so long as it is valid for your subnet, unused and ARP table has it listed with MAC of all FF's.

Now try waking with cell phone.

NOYB,

I will give it a try in the morning.

JohnnyBeGood

@NOYB:

JBG,

Before trying to wake them with the cell phone, go to Diagnostics - ARP Table. Is MAC and IP listed for machine? If not, that is why it won't wake up. It has been aged out of the ARP table. So that being the case the WoL 'Magic Packet' must be forwarded as a broadcast rather than to a specific machine. Try this…

Drop to a shell ( option 8 )
arp -s 192.168.1.254 ff:ff:ff:ff:ff:ff
arp -an (should see above entry)

Configure Firewall NAT Rule to forward your cell phone WoL to 192.168.1.254

Obviously replace above ip address with one appropriate for your network. Doesn't really matter what it is so long as it is valid for your subnet, unused and ARP table has it listed with MAC of all FF's.

Now try waking with cell phone.

NOYB,

You are the man! It works great now! Thank you!

Diagnostics - ARP Table shows each ip with all f's. I have not had a chance to check if HTPC was in ARP table before trying to wake it up.

NOYB

@JohnnyBeGood:

Diagnostics - ARP Table shows each ip with all f's.

No, no, no. Each machine IP should not have all F's MAC. Each machine should still have it's ordinary unique MAC address.

Only a dedicated IP address, that is otherwise unused, should have all F's MAC in ARP Table.
That IP address / MAC pair can then be used to forward WoL packets as an ethernet broadcast.

Such as 192.168.1.254 which is established by command: arp -s 192.168.1.254 ff:ff:ff:ff:ff:ff
And your firewall NAT rule should be config'd to forward the WoL packets to that address.

Hope that is what you actually did and not assign each machine an all F's MAC.

JohnnyBeGood

@NOYB:

@JohnnyBeGood:

Diagnostics - ARP Table shows each ip with all f's.

No, no, no. Each machine IP should not have all F's MAC. Each machine should still have it's ordinary unique MAC address.

Only a dedicated IP address, that is otherwise unused, should have all F's MAC in ARP Table.
That IP address / MAC pair can then be used to forward WoL packets as an ethernet broadcast.

Such as 192.168.1.254 which is established by command: arp -s 192.168.1.254 ff:ff:ff:ff:ff:ff
And your firewall NAT rule should be config'd to forward the WoL packets to that address.

Hope that is what you actually did and not assign each machine an all F's MAC.

That’s exactly what I did :)

I’ve assigned all F’s to each machine and it still worked. I was able to wake each machine individually but I was not able to browse that machine
Shared folder. Then I used
Arp –d 192.168.1.101
And deleted arp record then I added it again but this time with real IP and MAC.
I did not used this arp -s 192.168.1.254 ff:ff:ff:ff:ff:ff command and it still worked!
I’ll test in the morning to see if works after being in standby over night.
It should because when I do arp –an each ip has this ? (192.168.1.101) at 1c:6f:65xx:xx on em0 permanent [ethernet]

NOYB

Those ARP table entries will not survive a router reboot nor some router config changes.

To make static ARP table entries and have them survive a router reboot and interfaces config changes, try this little attached patch. It's very small and simple enough to do by hand if desired.

Then just put ARP entries (IP MAC pairs) in /var/etc/Static_ARPs.conf and the ARP entries will be created at boot up or when an interface change is made.

I'd dedicate an IP address to being an ethernet broadcast (all F's MAC) rather than making a permanent ARP entry for each machine. Then just forward WoL to that IP address and the WoL Magic Packet is broadcast on the LAN as it should be, and the machine who’s MAC is in the Magic Packet payload wakes up.

Static.ARP.Entries.patch.txt

JohnnyBeGood

@NOYB:

Those ARP table entries will not survive a router reboot nor some router config changes.

To make static ARP table entries and have them survive a router reboot and interfaces config changes, try this little attached patch. It's very small and simple enough to do by hand if desired.

Then just put ARP entries (IP MAC pairs) in /var/etc/Static_ARPs.conf and the ARP entries will be created at boot up or when an interface change is made.

I'd dedicate an IP address to being an ethernet broadcast (all F's MAC) rather than making a permanent ARP entry for each machine. Then just forward WoL to that IP address and the WoL Magic Packet is broadcast on the LAN as it should be, and the machine who’s MAC is in the Magic Packet payload wakes up.

You were right. It did not survive reboot.

I've tried to follow your instructions but after reboot I don't get any permanent arp tables with command: arp an
I've placed attached file Static.ARP.Entries.patch in /var/etc
then I created new file Static_ARPs.conf in /var/etc with following entries (last four have been masked for the security)
arp -s 192.168.1.101 1c:6f:65xx:xx
arp -s 192.168.1.100 bc:ae:c5:18:xx:xx
arp -s 192.168.1.102 00:18:f3:76:xx:xx

Appreciate your help!

NOYB

The patch has to be applied by either using the patch command or manually adding the appropriate contents to /etc/inc/interfaces.inc and /var/etc/Static_ARPs.conf.

For example: patch -p0 -i Static.ARP.Entry.patch.txt

JohnnyBeGood

Sorry for the late response….

Here's what I did:
Inside /var/etc/Static_ARPs.conf placed 3 entires in this format
192.168.1.101 1c:6f:65xx:xx
192.168.1.100 bc:ae:c5:18:xx:xx
192.168.1.102 00:18:f3:76:xx:xx

Then I run patch command here's the output:


[2.0-RC3][root@pfsense.router]/root(6): patch -p0 -i  Static.ARP.Entries.patch.txt
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /etc/inc/interfaces.inc    2011-08-31 12:32:37.000000000 -0700
|+++ /etc/inc/interfaces.inc.patched    2011-08-31 21:52:13.000000000 -0700
--------------------------
Patching file /etc/inc/interfaces.inc using Plan A...
Hunk #1 succeeded at 3959 (offset -13 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /var/etc/Static_ARPs.conf  1969-12-31 16:00:00.000000000 -0800
|+++ /var/etc/Static_ARPs.conf.patched  2011-08-31 20:29:06.000000000 -0700
--------------------------
Patching file /var/etc/Static_ARPs.conf using Plan A...
Hunk #1 succeeded at 1.
done
[2.0-RC3][root@pfsense.router]/root(7):

I will give it a test tomorrow morning.

NOYB

In order for the Static ARP entries to be applied to the ARP table at least one of the following must occur.

Reboot
An Interface Config Change
DNSMASQ Service Restart (Status: Services)

To verify run shell command arp -an and look for permanent entries.

I see Hunk #1 succeeded ant 3959 (offset -13 lines). Patch has been updated with correct target line number (3814) so that shouldn't happen anymore. Unless your interfaces.inc has other previous modifications.

To verify the patch applied correctly check the end of /etc/interfaces.inc. If patch applied correctly, it should look like this.


	/* Enable staticarp, if enabled */
	if(isset($config['dhcpd'][$if]['staticarp'])) {
		mwexec("/sbin/ifconfig " . escapeshellarg($ifcfg['if']) . " staticarp " );
		mwexec("/usr/sbin/arp -d -i " . escapeshellarg($ifcfg['if']) . " -a > /dev/null 2>&1 ");
		if (is_array($config['dhcpd'][$if]['staticmap'])) {

			foreach ($config['dhcpd'][$if]['staticmap'] as $arpent) {
				mwexec("/usr/sbin/arp -s " . escapeshellarg($arpent['ipaddr']) . " " . escapeshellarg($arpent['mac']));

			}

		}
	} else {
		mwexec("/sbin/ifconfig " . escapeshellarg($ifcfg['if']) . " -staticarp " );
		mwexec("/usr/sbin/arp -d -i " . escapeshellarg($ifcfg['if']) . " -a > /dev/null 2>&1 ");
	}

	exec("/usr/sbin/arp -f /var/etc/Static_ARPs.conf");	// This is the new line for Static ARPs.

	return 0;
}

JohnnyBeGood

It works!

I did reboot and after issuing arp -an I see each ip with permanent at the end


? (192.168.1.100) at bc:ae:c5:18:xx:xx on em0 permanent [ethernet]

I've also checked /etc/inc/interfaces.inc and it shows on the bottom what you've quoted above.

Would you know if this is something that would be implemented in pfSense 2.0 final or that's just a nature of the beast?

Thank you for your help!!!

NOYB

I am not the authority, but no, it won't be part of 2.0.

I for one would like to see GUI support for such a static ARP capability feature. But far as I know it is not planned for any future version. But I'm not in the loop about such things, so even if it was I probably would not know.

Recommend submitting a feature request if you would like to see static ARP capability such as or similar to this in a future version.