Want to remotely access computers behind your Bering firewall, but they aren’t turned on? You need the Wake-On-Lan Proxy written by Ken Yap.
Wake-On-Lan (WOL) is a technology that lets you turn on a computer on your network by sending a special packet to it over the network. The WOL proxy makes it easy to send these packets to your network from anywhere on the Internet, securely. It consists of a server (wold) and a client (wolc.pl). When the client sends the right password to the server, the server sends a WOL packet to the target computer.
If you want to set this up on your Bering firewall, first get WOL working. It is hard to debug, so it is best to get this out of the way before you add the proxy into the mix.
- Load the etherw package onto your firewall. This lets you send WOL packets when you are logged into the firewall.
- Make sure the target computer supports WOL and has it enabled in the BIOS
- The OS on the target machine has to leave the network card in a WOL-ready state when it shuts down. Instructions for linux and windows. Here is how I set up my Shuttle SK41G for WOL
- Turn off the target machine and send a WOL packet from the firewall:
ether-wake 00:AA:BB:CC:DD:EE -i eth1
The target machine should turn on
Once you have basic WOL working, it is time to set up the proxy:
- Load the wold.lrp package onto the firewall
- Go into “lrcfg”–>”packages”–>”wold” to edit the configuration file (/etc/wold.conf). Add the target machine’s MAC address, name, and password. You will need the same configuration file for the client
- Add wold to the list of services (/etc/services) and give it a port number:
...
# Local services
wold 54321/tcp # WOL proxy
wold 54321/udp # WOL proxy
...
- Configure inetd.conf to run wold when the client connects.
...
wold stream tcp nowait sh-httpd /usr/sbin/tcpd /usr/sbin/wold \
-f /etc/wold.conf -i 192.168.1.255 -p 54321
...
Restart inetd (run svi inetd resart).
- Configure hosts.allow to allow machines to connect to the firewall
- Edit the shorewall rules file to allow incoming wold connections from the local network and the internet, and to allow outgoing WOL packets to the local network.
...
# Allow WOLD requests to the firewall from anywhere,
# Allow WOLD magic packets from the firewall to local
ACCEPT loc fw tcp 54321
ACCEPT net fw tcp 54321
ACCEPT fw loc udp 54321
...
Restart shorewall (run svi shorewall resart)
- Back up all the Bering packages you changed (wold, shorewall, etc)
- Grab the client (it is in the WOL proxy package, found here) and set it up with the same configuration file you used on the server (you can remove passwords if you want to be prompted). Run it like this:
$ ./wolc.pl -f wold.conf 192.168.1.254:54321 computer_name
This is the Wake-On-Lan Proxy 0.5 written by Ken Yap, packaged for Bering firewalls. Only the daemon is included in the .lrp package, since that is the part that needs to run on the firewall.
Download wold.lrp version 0.5
I also wrote a short explanation of how to set this up here.
The Bering installation instructions explain how to configure Bering on the firewall machine itself, by using the lrcfg program and backing up the files to the floppy disks. Sometimes I find it more convenient to edit configuration files on my desktop computer, and then copy the new image to floppy disk. (I have a linux desktop, by the way. I’m not sure how to do this on windows)
Here’s how I do it:
- Mount the disk image as a loopback filesystem:
$ mkdir mount_directory
$ mount -o loop -o umask=000 diskimage.bin mount_directory
- Some files, like syslinux.cfg, can be edited directly
- lrp packages need to be uncompressed before they can be edited. This has to happen in a temporary directory outside the mounted disk image, since there won’t be enough room inside the mount directory:
$ mkdir package_directory
$ cd package_directory
$ tar -zxvf ../mount_directory/package.lrp
- After editing files in the package, re-compress it and replace the original lrp file:
$ tar -cvf package.tar *
$ gzip -9 package.tar
$ cp package.tar.gz ../mount_directory/package.lrp
- Finally, unmount the image:
If you want to test your images before unmounting them, call sync first to make sure the images are up to date.
dhcp_2_dns.sh is a script which updates tinydns with addresses handed out by dhcpd. This is useful for Bering firewalls because DNS and DHCP will be synchronized.
Here’s how to set it up:
- First, make sure tinydns is set up and running (directions are here).
- Copy dhcp_2_dns.sh onto your firewall. I put my copy in /usr/bin/. Add /usr/bin/dhcp_2_dns.sh to /var/lib/lrpkg/tinydns.list:
...
usr/bin/tinydns-data
usr/bin/dhcp_2_dns.sh
etc/tinydns-private/
...
(This adds dhcp_2_dns.sh to the tinydns.lrp package).
- Edit /etc/init.d/tinydns so that dhcp_2_dns.sh is run every time tinydns starts. Add the call near the end of set_dnscache():
...
echo "" > /var/run/resetdns.pid
/usr/bin/dhcp_2_dns.sh # run dhcp_2_dns.sh
RESET_DNS=Y
}
...
- Back up tinydns.lrp
- Edit /etc/multicron-p and add dhcp_2_dns.sh to periodic():
periodic () {
checkfreespace
pingcheck
/usr/bin/dhcp_2_dns.sh
}
By default, periodic() is run every 15 minutes. This can be changed in /etc/cron.d/multicron.
- Back up etc.lrp
This is an update to Michael D. Schleif’s dhcp_2_dns.sh script, which updates tinydns with addresses handed out by dhcpd. This includes the following changes from version 0.1:
- Fixed “out of range” problem when comparing lease dates
- Fixed problem where DNS entries were never replaced when a host’s address
changed
- New feature: fixed-address entries (from dhcpd.conf) are now added to the
DNS server
Download dhcp_2_dns.sh 0.2
I also have some simple directions for setting this up on a Bering firewall