Yes? Whats up with this page?
Ah - do you mean, if i can wakup the server from the WOL-Page of the Fire? Yes i can.
Within the LAN all is working fine
Will it wake up from this page or from your phone on your LAN.
Both is working but âonlyâ within my LAN - not from outsideâŚ
Looks bad for Firewall.
Sorry I couldnât be of more help.
Yep - i know 
The rule should be:
source Any
NAT clicked (firewall automatic)
Destination 172.16.0.255 (if your internal net is 172.16.0.0)
Protocol UDP
save, apply changes.
Give it a try.
Yes⌠i know⌠but its ânotâ workingâŚ
This is the âWake on WANâ firewall rule which was working several years⌠but it doesnt anymoreâŚ
Who knows, what the problem is? I dontâŚ
FYI: The Rule is working again with Core 153 - but not with port 9 - its port 7 now 
EDIT: After i activated the Location Block System, NOTHING is working again⌠i switched off the Location Block, but no chance⌠not working (again) anymoreâŚdisappointing 
Is it possible to deinstall this GeoBlock-Garbage? For what is this for, if its not workingâŚ
Hi,
so the Core Update changed the port number of a firewall rule?! This really should not happenâŚ
Are you using the latest location database? What do you mean exactly by ânothing is workingâ?
Please run location update on your machine and post its output here.
Thanks, and best regards,
Peter MĂźller
Peter⌠the rule (from the screenshot) âis not workingââŚ
Port forwarding âis not workingâ.
A WOL-Broadcast from Port 55000 will not be forwarded to port 9.
I did the location update - Output: Already on the latest version.
It was working after the update to core 153 (LocationBlock was OFF), but ONLY on port 7(?), then i activated LocationBlock > NOT WORKING, deactivated LocationBlock again > STILL NOT WORKING!!! What is thisâŚ
Can someone from the developers please test whether he can bring a computer out of sleep from outside the LAN via a WOL broadcast?
I âurgentlyâ need this function.
Thanks for your help and support
EDIT: Here an additional Screenshot from the firewall-log and the WoW-rule.
On port 9, it says âDISCARDâ ??? Why?
I canât help you with testing WOL from the internet as I always do this via an OpenVPN tunnel and then use the IPFire WOL page to start any computers I want started.
I can say that the Port Forwards I have in place for things like web access and webmail were working with Core 152 and are still working with Core 153 update that I did yesterday.
Port 9 is officially classified as the DISCARD port by IANA. This is why you see that name next to the port number. Wake-on-Lan also uses port 9 but it is an unofficial usage.
This link covers the use of the DISCARD protocol and mentions that it uses port 9
https://en.wikipedia.org/wiki/Discard_Protocol
So use of the word DISCARD in the logs for port 9 is nothing to worry about.
Sorry that I canât help you further with your wol port forward problem.
Hi Adolf,
the question was not: What is the discard-protocol, the question was: WHY is it at the log when it was working for many years?
I know the discard protocol and its funktion but the status at the moment is: The firewall âdoes notâ forward packages⌠so port forwarding is partly or complete brokenâŚ
So⌠whats the conclusion now?
Is it recommended to reinstall ipfire?
Will this help or fix the problem?
Is the firewalll broken?
Any statement from the Devs?
Thanks for your help
Hi @zonediver,
Looking at the log page provided, what I see is that the port forward was successfully carried out. The DNAT shows the transfer from the internet address to your IPFire followed by the FORWARDFW for the onward transmission to the computer on your network. This is the same as I find in my logs for my successful port forwards for my webmail access but with port 443(HTTPS). I have those messages with Core 153 and 152.
What I notice is that an actual specific IP has been used rather than the broadcast address for the network. My understanding of the WOL protocol is that it is a broadcast approach because when the computer is turned off the network card is awake enough to recognise the magic packet related to its MAC address but it has no knowledge of what its IP address will be. Therefore the port forward of the WOL should be to the network broadcast address, 192.168.2.255, which means that the message goes to all computers on that network.
Although the earlier posts say the WOL forward has successfully worked with the specific computer IP in the past, it might be worth trying with the broadcast address for the network that the computer is on.
If that doesnât work then it could be useful to have a screenshot of the firewall rules.
Hi Adolf and thanks for your help
The rule is the same as before - just with the braodcast-addressâŚ
Itâs not workingâŚ
So the broadcast address is getting dropped. That suggests that there is an implicit rule in IPFire that drops forwarding of broadcast addresses.
The only thing I can think of then is that the original NIC somehow kept some knowledge of the IP address it had when it was turned on and the replacement NIC doesnât.
Is there any possibility to replace the original NIC as a test or did you change it as it was broken.
Beyond that I have run out of ideas. Sorry.
Not really⌠the last NIC was an OnBoard NIC from a changed Mainboard of my Plex-Server.
The new NIC is an Intel i210AT - the same as i use on my IPFire.
It seems i have to reinstall the whole fire because i have also problems with the old IPs of the Server.
They are still at the ARP-cache and cant be deleted - maybe a second bug at the IPFireâŚ
WOL is all magic to me.
I thought it was dependent on MAC address?
More Information on Wake-on-LAN
The standard magic packet used to wake a computer works below the Internet Protocol layer, so itâs usually unnecessary to specify IP address or DNS information. A MAC address is normally required, instead. However, this isnât always the case, and sometimes a subnet mask is needed.
Try MAC or whole Network
MAC address
192.168.1.1/24
Thats not possible with NAT - the IPFire prevents thisâŚ