I’ve got an RB-750G on which I have Firewall filter rules and DstNat rules for being able to send a machine on the LAN side of the RB-750G Wake On Lan magic packets, UDP packets on ports 7 or 9. But the weirdness is this. On the internet facing interface I only have allow rules for specific ports (ports 7 and 9 as well as others), as well as an allow rule for Established connections and Related connections and then I end with a non-specific drop rule so anything that doesn’t meet any of the preceeding “allow” rules gets dropped. But my Wake On Lan ports are getting in to the LAN without passing the filter rule I created for them as evidenced by the packet count for the rule staying at zero. In fact I can’t figure out how they’re getting in. The DstNat rule does show the packet count increment when I send packets from the internet. How are those tricky packets getting in past the firewall? And if they’re getting in without explanation then what else is getting in?
Does an open connection between the router and my computer (via WinBox for example) mean that the connection is considered “established” for a connection on any port? I would think not.
seems like WOL (and DHCP, for example) uses RAW sockets, so you can only catch those packets by bridge filter. if you need it on single interface - you can create a bridge and add that interface as bridge port, then bridge filter will work for that interface
I don’t quite get your question m8. Could you please explain more clearly? Perhaps a more concrete example would help.
I even want to test it for you on my setup.
If a connection is initiated from the WAN, the firewall should not allow this traffic (so it should block it) unless you forward specific ports to one of your hosts. Established traffic should be allowed because a client on your LAN initiated the connection and otherwise it would not be able to recieve a reply coming from the WAN. With connection tracking, establishing a TCP-connection on port 80 of some webserver, does not imply this webserver can now send WOL packets to your clients on other ports.
At any rate, I’m totally confused by how you ask your question. But interested though!
Well it appears that your assumption (which was mine originally) that “if a connection is initiated from the WAN, the firewall should not allow this traffic (so it should block it) unless you forward specific ports to one of your hosts.” doesn’t hold true. For these “raw” packets those rules don’t apply. According to what I found via Google raw packets are not subject to the normal processing and assembly/disassembly so they pass right through. It’s why they’re called raw. I guess there’s not much we can do about them. I think I’d like to at the very least know what they’re doing
Then I should find out what a raw packet is also. Can you explain how you test? I want to try this 4 myself…
I do not know how intimate your knowledge with IP Tables is, but packets not destined for the router can be filtered at the input chain (I’m not very good with IP Tables either lolz).
Here’s the test. Don’t make a filter rule for the UDP port 7. Then set up a DstNat rule for UDP port 7 to a particular machine. From the outside send a wake on lan packet on UDP port 7. Watch the DstNat rule’s packet counter increment.
You can’t filter the WOL packet because it doesn’t transverse the filtering. It’s a raw packet and bypasses much of the router’s workings.
Thanks I’ll try that. And I meant forward chain in my previous post. I think I can explain what happens but I’ll need to see it first.
So from the outside you mean I can just send a WOL packet from a site like depicus.com?
After reading up I must conclude a raw socket can only be opened on a host where you have root access. A raw socket indeed bypasses the TCP/IP stack (and perhaps this way you can bypass iptables on the router) but I don’t see how this can be done over the internet (unless someone has access to your router by hacking it somehow).
The threat you fear is thus something else:
Raw sockets allow you to craft your own packets and manipulate every aspect of a packet. This appears to be used for tools like traceroute and ping (ICMP). Of course hackers can also use raw sockets to their advantage. By building badly formed packets they can perform various attacks on servers or routers or anything else connected to the internet(for instance syn-flooding).
On the other hand, there are also many legitimate uses for raw sockets. On of these is NAT for instance: the ability to change the source and destination address in the IP-header. I’m sure there are many more:).
To conclude my post, there is probably something ‘wrong’ with your rules. I’m guessing there is some combination allowing the packet to slip through. I have not yet finished reading up on how iptables works exactly, but I’m thinking the NAT table is hit before the input/forward/output tables and this is allowing the packet through the firewall.
I hope this helps and I’m happy to get corrected if the above is absolute nonsense.
Yeah, that was my expectation too. But I sit here watching the router in question from the internet side (I’m in Venezuela, the router is in NY) and I’m sending it WOL packets and they’re going right past the firewall and to the machine that I have the WOL packets directed to via DstNat. I remote control the PC that is the destination of those WOL packets and I see it receive them. So I can tell you for sure, that a WOL packet sent from the internet will go past your firewall. Now if you don’t have a DstNat redirecting them then I guess they just die in the router. I guess.
Read my other post. This does not require someone to have root access to the router.
What I’m wondering is what will happen when IPv6 is implemented and there is no more nat, and everything is exposed to the web. I think I’m going to be running Astaro on my network’s edge when that happens.
Sorry for my english. I don’t mean wrong as in ‘your fault’. I mean I think the rules are simply behaving correctly.
If the NAT table is hit first, you might not be able to stop the packet anymore…
No problem. : - ) Thanks for the clarification, but no, the rules are working right. This is how it works. From what I read there are some routers that do stop WOL packets, and as the MT expert posted above, there is a way to make RouterOS stop them too if you want to. Sounds like you just need to put the public (WAN) port on a bridge and then you can filter those packets. Though if you don’t have a nat rule forwarding them on they don’t go anywhere. But… some day we’ll be IPv6 without nat, and then what happens? I guess maybe the worst thing is hackers can wake your computers.
It sounds like IPv6 is still a work in progress with many issues and problems. It will be interesting to see how it all plays out. I suspect there’s going to be a big market for edge devices like Astaro.
(now watch, some Untangle troll will post, they always show up)
WOL doesn’t have to run on UDP/7. It traditionally does, but that is not at all a requirement. The NIC of a sleeping PC doesn’t look at protocol.
Magic Packet
The magic packet is a broadcast frame containing anywhere within its payload 6 bytes of all 255 (FF FF FF FF FF FF in hexadecimal), followed by sixteen repetitions of the target computer’s 48-bit MAC address.
Since the magic packet is only scanned for the string above, and not actually parsed by a full protocol stack, it may be sent as any network- and transport-layer protocol. It is typically sent as a UDP datagram to port 7 or 9, but actually it can be sent on any port.
Have you sniffed traffic to determine the actual packet that arrives at the computer by running wireshark or something comparable when it is awake and sending a WOL packet? It may not be what you’re expecting.
Raw sockets have absolutely nothing to do with transporting packets. A raw socket is simply a socket on a host that is listening for packets before they are processed by the TCP and UDP stacks of the operating system. That only applies to traffic TO a host/router, not traffic THROUGH a host/router.
Stateful firewalling works just fine in RouterOS, and it works just fine for IPv6, also.
Also, I’m curious what tool you’re using to send a WOL packet across a WAN? Since it’s sent to the broadcast address I just wonder how you’re destination NATing it (I can’t come up with the RouterOS NAT rule that would allow you to do this), and what tool allows you to send this as a unicast across the world instead. The output of “/ip firewall export” would also be useful since screenshots only show select columns. If you’re using subnet directed broadcasts the destination address would be the subnet IP. That would be in the ‘forward’ chain since it’s not an IP on a router interface. Your screenshots only show rules for the ‘input’ chain - you may not be aware of this, but that means you’re only protecting the router itself (traffic directly to the router, AFTER destination NAT). You’re letting all traffic through the router.
I think I know what Greg’s question is now. My penny dropped from reading his last post. The raw socket stuff has indeed little to do with it.
I think he wants to know how to filter a WOL packet when forwarding a port (any port) to a host.
Greg, is my assumption correct?
@fewi, a site called depicus.com allows you to create such packets. I use it all the time to wake up my pc from the WAN. I posted a link a few posts back.
ps: fewi is really smart with networking. We must both pay attention now:)
Wow, now we’re getting into it! Thanks for the great post. I’m going to respond inline.
I’m sending them on port 7 and port 9.
Have you sniffed traffic to determine the actual packet that arrives at the computer by running wireshark or something comparable when it is awake and sending a WOL packet? It may not be what you’re expecting.
No, I’m not using Wireshark. But I am running a little Windows app that can send and receive WOL packets, and I’m using that to indicate the received WOL packets.
Also, I’m curious what tool you’re using to send a WOL packet across a WAN? Since it’s sent to the broadcast address I just wonder how you’re destination NATing it (I can’t come up with the RouterOS NAT rule that would allow you to do this), and what tool allows you to send this as a unicast across the world instead. The output of “/ip firewall export” would also be useful since screenshots only show select columns. If you’re using subnet directed broadcasts the destination address would be the subnet IP. That would be in the ‘forward’ chain since it’s not an IP on a router interface. Your screenshots only show rules for the ‘input’ chain - you may not be aware of this, but that means you’re only protecting the router itself (traffic directly to the router, AFTER destination NAT). You’re letting all traffic through the router.
With both of those tools here in Venezuela I’m able to specify a single address instead of a network broadcast address, and my RB-750G in NY is receiving those packets and is DstNatting that to the PC in question.
If I change my “input” chain rules to “forward” rules then I’ll only be protecting the LAN and not the router right? So I need those rules duplicated in both chains to protect the router and the LAN?
Yes. Sort of. In input protect router services. SSH, Winbox, that sort of thing. In forward protect hosts behind the router. In input it often makes sense to just allow access from management subnets you control and not even filter by protocol. Generally duplicating all rules isn’t necessary.
Fewi - Thanks so much! I’m trying to make sure I understand what you’re saying. It sounds like in the previous email you’re saying regarding new connections initiated from the internet (WAN port) that a drop rule in the input chain only blocks communication between the WAN port and the router, but it doesn’t block communication from the WAN port to the LAN devices. Is that right? I thought if it gets dropped at the input chain it would get dropped no matter what it’s destination (router or LAN device).
Is it not like this?
WAN–(input rules, allows and drops)—(nat rules that match input allows)—(forward rules, controls traffic between nets)-(LAN)
Based on the above, regarding traffic coming from the internet and the connection is new (not an existing connection initiated by a device on the LAN) if input allows that traffic but it’s not natted onwards to the LAN then it only can reach the router (http/s, telnet, ssh, winbox). If it’s traffic/ports that the router doesn’t have services for then the traffic just dies.
If the type of traffic (connection initiated from the WAN side) is allowed at the input and there’s a nat rule for the type of incoming traffic then it will go on to the LAN assuming it’s not blocked in the forward rules.
The firewall operates by means of firewall rules. Each rule consists of two parts - the matcher which matches traffic flow against given conditions and the action which defines what to do with the matched packet.
Firewall filtering rules are grouped together in chains. It allows a packet to be matched against one common criterion in one chain, and then passed over for processing against some other common criteria to another chain. For example a packet should be matched against the IP address:port pair. Of course, it could be achieved by adding as many rules with IP address:port match as required to the forward chain, but a better way could be to add one rule that matches traffic from a particular IP address, e.g.: /ip firewall filter add src-address=1.1.1.2/32 jump-target=“mychain” and in case of successfull match passes control over the IP packet to some other chain, id est mychain in this example. Then rules that perform matching against separate ports can be added to mychain chain without specifying the IP addresses.
There are three predefined chains, which cannot be deleted:
input - used to process packets entering the router through one of the interfaces with the destination IP address which is one of the router’s addresses. Packets passing through the router are not processed against the rules of the input chain
forward - used to process packets passing through the router
output - used to process packets originated from the router and leaving it through one of the interfaces. Packets passing through the router are not processed against the rules of the output chain
Packet flow diagrams illustrate how packets are processed in RouterOS.
When processing a chain, rules are taken from the chain in the order they are listed there from top to bottom. If a packet matches the criteria of the rule, then the specified action is performed on it, and no more rules are processed in that chain (the exception is the passthrough action). If a packet has not matched any rule within the chain, then it is accepted.
Also see iptables man pages as this is based on Linux. The filter manual quote is slightly too short - see below for what really goes into the input chain when there is destination NAT.
A packet comes into the router from any interface. It is processed against firewall filters and mangle in prerouting. Then destination NAT happens (destination NAT at this point implicitly without any configured rules also undoes source NAT in the reverse flow direction). The destination IP is rewritten if required. Then the destination IP is looked at. If it is an IP on a router interface the packet goes into input, if it is not the packet goes into forward. Input chain packets end here. Forward and output (packets generated by a process on the router - you virtually never want firewall filters in the output chain) go into postrouting filter and mangle. Then source NAT happens (and also implicitly undoes destination NAT for packet flow in the reverse direction at this point).
That is a very abbreviated packet flow version focused on firewall facilities. The packet flow diagram has all the details. It is literally the single most important manual document to understand.
