Iptables: Logging connection attempts to offline device within LAN

In order to wake up a local NAS I require iptables to log connection attempts to the IP address of said target device. I installed kmod-br-netfilter and added net.bridge.bridge-nf-call-iptables=1 to /etc/sysctl.conf. I also added static DHCP entries for the target machine.

This is my /etc/firewall.user entry:

iptables -I FORWARD 1 -p all -d -m limit --limit 2/sec -j NFLOG --nflog-group 32 --nflog-prefix "WOL_LOG: "

However I'm only receiving log data when the target machine is online. Once it's suspended the logs are empty.

How would the entry have to look like in order to log connection attempts even when the machine is offline?

@Reutertu3, welcome to the community!

If the machine offline, there is no ARP responding...

Have you tried logging ARP requests?

(I don't know why one would use this method unless it's just local, so i'm not understanding the need for a firewall rule, how you "wake up", etc.)

3 Likes

Hi.

Thanks for your reply!. Yeah that sounds rather logical, I will attempt logging ARP requests.

It's indeed just a local machine. A machine that's running OpenMediaVault which I intend to wake up via WoL when it's requested.

Why don't you have them request the WoL machine?

I wouldn't know how to go on about it.

Ideally just opening the OMV webinterface or trying to access the Samba share triggers the script to send a magic packet.

There is a problem with your plan, or actually two orthogonal ones.

  • the (typically-) four LAN ports are usually bridged inside your router's hardware switch, as a consequence the kernel (and with that the netfilter code) doesn't get to see the LAN traffic (yes, ARP requests are slightly different).
  • if you break up this hardware bridge and force the kernel to bridge in software, you suddenly need a lot more hardware resources to keep up.

While technically possible (with the caveats above), I don't think opening this can of worms would be a good idea.

2 Likes

Yes, this is indeed introducing problems that I had absolutely no knowledge about. That also explains why my attempts with ebtables were rather fruitless.

On the other hand that would also mean, that a secondary OpenWRT device dedicated to the NAS would possibly solve my issue, right? I know it would be rather silly and just manually sending magic packets via a desktop shortcut or something would solve the issue as well. But I'm somewhat determined to find a "lazy" solution.

Before I was an Asus Merlin user, I used a script to wake up a server outside the local network, I leave the link in case it is helpful

1 Like

Small update on the issue, which turned out to be quite a ride.

Whilst messing around with the 2 router setup I managed to brick my main router (WRD3600) with the wrong firmware. It then refused to accept a TFTP recovery, no matter what kind of firmware (stripped, correct bytesize) I uploaded. Thus the only way of rescue was a recovery via serial port, which was a first for me. And this one's for Google: A CH340 uart adapter doesn't work out of the box and only outputs gibberish. Probably due to some missing pullup resistors, but I didn't bother with it cause a CP2102 works just fine out of the box.

But back to the original issue: It kinda works, but I'm still experiencing seemingly odd behavior. I added these two firewall rules to see what's being logged:

iptables -I FORWARD 1 -p all -d <target IP> -i br-lan -m limit --limit 2/sec -j NFLOG --nflog-group 12 --nflog-prefix "Fuji_LOG:  "
ebtables -I FORWARD 1 -p ARP -i br-lan -d <target MAC> --nflog-group 12 --nflog-prefix "Fuji_ARP:  "

And indeed after the machine goes offline I'm receiving these kind of logs:

Mar 18 07:46:00 Watchdog Fuji_LOG:   IN=br-lan OUT=br-lan MAC=xxx SRC=xxx DST=xxxLEN=1152 TOS=00 PREC=0x00 TTL=64 ID=55479 DF >
Mar 18 07:46:07 Watchdog Fuji_LOG:   IN=br-lan OUT=br-lan MAC=xxx SRC=xxx DST=xxx LEN=60 TOS=00 PREC=0x00 TTL=64 ID=30719 DF PR>
Mar 18 07:46:11 Watchdog Fuji_ARP:   IN=br-lan OUT=br-lan MAC=xxx SRC=xxx DST=xxx PROTO=ARP REQUEST MARK=0
Mar 18 07:46:11 Watchdog Fuji_ARP:   IN=br-lan OUT=br-lan MAC=xxx SRC=xxx DST=xxx PROTO=ARP REQUEST MARK=0
Mar 18 07:46:12 Watchdog Fuji_ARP:   IN=br-lan OUT=br-lan MAC=xxx SRC=xxx DST=xxx PROTO=ARP REQUEST MARK=0
Mar 18 07:46:12 Watchdog Fuji_ARP:   IN=br-lan OUT=br-lan MAC=xxx SRC=xxx DST=xxx PROTO=ARP REQUEST MARK=0
Mar 18 07:46:13 Watchdog Fuji_LOG:   IN=br-lan OUT=br-lan MAC=xxx SRC=xxx DST=xxx LEN=60 TOS=00 PREC=0x00 TTL=64 ID=8547 DF PRO>
Mar 18 07:46:13 Watchdog Fuji_ARP:   IN=br-lan OUT=br-lan MAC=xxx SRC=xxx DST=xxx PROTO=ARP REQUEST MARK=0
Mar 18 07:46:13 Watchdog Fuji_ARP:   IN=br-lan OUT=br-lan MAC=xxx SRC=xxx DST=xxx PROTO=ARP REQUEST MARK=0

However after a certain amount of time passes there are no new log entries being generated.

Both routers have permanent and correct arp entries. My Laptop as a client however did not. But once I manually added an arp entry on that machine, the iptables entry started logging again without any flaws. Hence I'm wondering if that was the issue all along?

If this manual entry sticks and iptables keeps logging under these circumstances and with the target machine being offline, then the initial problem should be solved.