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.

Thanks!
Greg

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

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

Thanks for the reply!

Should I be afraid? It makes me wonder what else blows right past the firewall. It's time for me to Google raw sockets.

Thanks!

Greg

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!

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

Is there any way to log raw packets?

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).

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.

Chupaka tells how to filter those packets.

Greg

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?

http://www.depicus.com/wake-on-lan/woli.aspx

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.

snip
If I do not have a rule in the forward chain that allows traffic to UDP port 7, and I have a rule at the end of the forward chain that says drop ALL traffic, I would expect the WOL packet to be dropped.
snip

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.

Greg

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).

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.

Greg

snip
To conclude my post, there is probably something 'wrong' with your rules.
snip

Uh... wrong.

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...


This tought me everything I know about raw sockets. I fail to see how they are an immediate threat from the WAN, aside from hackers building tools with this and launching some kind of attack. http://www.sans.org/reading_room/whitep ... efully_289

Sorry for my english. I don't mean wrong as in 'your fault'. I mean I think the rules are 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.

http://en.wikipedia.org/wiki/Wake-on-LAN

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.

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.

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.

I'm using Magic Packet Sender from http://MagicPacket.Free.FR on the PC side and Depicus' Wake On Lan from http://www.depicus.com on the Mac side.

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?

Thank so much!!!

Greg

Thanks for the product info.

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.

Thanks for the product info.

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.

Is that not right?

Thanks!
Greg

No. You have that completely wrong.

http://wiki.mikrotik.com/wiki/Manual:IP ... ter#Chains

Chains

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.

http://wiki.mikrotik.com/wiki/Manual:Packet_Flow

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.

Can you confirm that you have "switch-all-ports=yes"?
I may have an idea, that bothers me for a couple of time now.

No. You have that completely wrong.

http://wiki.mikrotik.com/wiki/Manual:IP ... ter#Chains

Chains

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.

http://wiki.mikrotik.com/wiki/Manual:Packet_Flow

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.

Fewi - Thanks for all that information! I do understand the router's function better now. I see that what I originally thought was technically wrong (I incorrectly thought the input chain handled all inbound traffic regardless of destination) but my diagram above is correct as far as what happens in the case I was talking about which is when a new connection is attempted from the WAN side and all LAN traffic is natted. An attempted inbound connection has to be sent to the router's address if the router's WAN port is using a public IP address and all LAN IPs are not publicly reachable and their traffic is natted. A new connection initiated on the WAN side has no masquerade rule so the router will see that traffic as destined for itself (it's interfaces) and will handle that traffic using the rules in the input chain. If the traffic in this case is allowed in the input chain AND there's a matching DstNat rule then the traffic will be routed to the LAN and that traffic will then be handled by the forward chain.

So even though technically the input chain only sees traffic destined for the router's interfaces new connections from the WAN side will be seen as traffic destined for the router's interfaces IF the devices behind the router are natted and unreachable from the internet and there's no masquerade rule for that traffic. In that condition traffic can only be sent to the router. Once the traffic meets conditions which destine it for the LAN due to DstNat or masquerade rules then it is no longer handled by the input chain but then it would be handled by the forward chain. Do I understand it this time?

Back to my initial topic, for some reason WOL packets are not handled by the input chain even though I'm sending them to the router's IP address but also the PC's MAC address. WOL packets can't be blocked there nor explicitly passed in the input chain, they get through whether or not there's a matching rule. But for whatever reason WOL packets are handled by the NAT section of the router.

Greg

Please post the output of "/ip firewall export" and confirm that you're sending traffic to udp/7.

You cannot be sending traffic to the PC's MAC address as it isn't part of your local network. The MAC address may be embedded in the payload, but it most certainly isn't embedded in the layer 2 header.

As for me, I would like to see "your" /interface ethernet switch print please.

As for me, I would like to see "your" /interface ethernet switch print please.

# apr/14/2011 15:26:42 by RouterOS 5.1
/interface ethernet switch port
set ether1-gateway vlan-header=leave-as-is vlan-mode=fallback
set ether2-local-master vlan-header=leave-as-is vlan-mode=fallback
set ether3-local-slave vlan-header=leave-as-is vlan-mode=fallback
set ether4-local-slave vlan-header=leave-as-is vlan-mode=fallback
set ether5-local-slave vlan-header=leave-as-is vlan-mode=fallback
set switch1_cpu vlan-header=leave-as-is vlan-mode=fallback

Please post the output of "/ip firewall export" and confirm that you're sending traffic to udp/7.

You cannot be sending traffic to the PC's MAC address as it isn't part of your local network. The MAC address may be embedded in the payload, but it most certainly isn't embedded in the layer 2 header.

# apr/14/2011 15:01:42 by RouterOS 5.1
/ip firewall layer7-protocol
I cut this out because it was huge.
/ip firewall address-list
add address=192.168.1.0/24 disabled=no list=QOSCustomerIPs
add address=10.10.10.10 comment=\
"Example for the DoNotTestConnectionCounts list" disabled=yes list=\
DoNotTestConnectionCounts
/ip firewall connection tracking
set enabled=yes generic-timeout=10m icmp-timeout=10s tcp-close-timeout=10s \
tcp-close-wait-timeout=10s tcp-established-timeout=1d \
tcp-fin-wait-timeout=10s tcp-last-ack-timeout=10s \
tcp-syn-received-timeout=5s tcp-syn-sent-timeout=5s tcp-syncookie=no \
tcp-time-wait-timeout=10s udp-stream-timeout=3m udp-timeout=10s
/ip firewall filter
add action=tarpit chain=input comment="Tarpit ssh brute forcers" disabled=no \
dst-port=22 protocol=tcp src-address-list=ssh_blacklist
add action=add-src-to-address-list address-list=ssh_blacklist \
address-list-timeout=1w3d chain=input connection-state=new disabled=no \
dst-port=22 protocol=tcp src-address-list=ssh_stage3
add action=add-src-to-address-list address-list=ssh_stage3 \
address-list-timeout=1m chain=input connection-state=new disabled=no \
dst-port=22 protocol=tcp src-address-list=ssh_stage2
add action=add-src-to-address-list address-list=ssh_stage2 \
address-list-timeout=1m chain=input connection-state=new disabled=no \
dst-port=22 protocol=tcp src-address-list=ssh_stage1
add action=add-src-to-address-list address-list=ssh_stage1 \
address-list-timeout=1m chain=input connection-state=new disabled=no \
dst-port=22 protocol=tcp
add action=tarpit chain=input comment="Tarpit FTP" disabled=no dst-port=21 \
protocol=tcp
add action=tarpit chain=input comment="Tarpit telnet" disabled=no dst-port=23 \
protocol=tcp
add action=accept chain=input comment="Allow 53 Inbound" disabled=no \
dst-port=53 in-interface=ether1-gateway protocol=tcp
add action=accept chain=input comment="Allow 54 Inbound" disabled=no \
dst-port=54 in-interface=ether1-gateway protocol=tcp
add action=accept chain=input comment="Allow 123 Inbound" disabled=no \
dst-port=123 in-interface=ether1-gateway protocol=tcp
add action=accept chain=input comment="Allow SSH Inbound" disabled=no \
dst-port=22 in-interface=ether1-gateway protocol=tcp
add action=accept chain=input comment="Allow WebBox Inbound" disabled=no \
dst-port=8291 in-interface=ether1-gateway protocol=tcp
add action=accept chain=input comment="Allow Apple Remote Desktop" disabled=\
no dst-port=3283,3284,5900,5901 in-interface=ether1-gateway protocol=tcp
add action=accept chain=input comment="Allow Apple Remote Desktop" disabled=\
no dst-port=3283,3284,5900,5901 in-interface=ether1-gateway protocol=udp
add action=accept chain=input comment="Allow Ports 1280-1282" disabled=no \
dst-port=1280,1281,1282,1283 in-interface=ether1-gateway protocol=tcp
add action=accept chain=input comment="Allow limited pings" disabled=no \
in-interface=ether1-gateway limit=50/5s,2 protocol=icmp
add action=drop chain=input comment="Drop excess pings" disabled=no \
in-interface=ether1-gateway protocol=icmp
add action=accept chain=input comment="Added by webbox Allow Established" \
connection-state=established disabled=no in-interface=ether1-gateway
add action=accept chain=input comment="Added by webbox Allow Related" \
connection-state=related disabled=no in-interface=ether1-gateway
add action=accept chain=input comment="Allow SYN" disabled=no protocol=tcp \
tcp-flags=ack
add action=accept chain=input comment="Allow RST" disabled=no protocol=tcp \
tcp-flags=rst
add action=drop chain=input comment="Added by webbox" disabled=no \
in-interface=ether1-gateway
/ip firewall mangle
add action=accept chain=forward comment=\
"Accept all traffic going to the RouterIPs address list - Leave disabled" \
disabled=yes dst-address-list=RouterIPs
add action=mark-packet chain=forward comment=\
"We should start with marking everything as unknown - p6" disabled=yes \
new-packet-mark=p6 passthrough=yes
add action=mark-connection chain=forward comment=Skype-to-skype disabled=no \
layer7-protocol=skypetoskype new-connection-mark=Skype passthrough=yes
add action=mark-connection chain=forward comment=Skype-to-skype disabled=no \
layer7-protocol=skypeout new-connection-mark=Skype passthrough=yes
add action=mark-packet chain=forward comment=\
"Skype-to-skype p1 with NO PASSTHROUGH" connection-mark=Skype disabled=no \
new-packet-mark=p1 passthrough=no
add action=mark-packet chain=forward comment="Ack to p1" disabled=no \
new-packet-mark=p1 packet-size=0-40 passthrough=no protocol=tcp \
tcp-flags=ack
add action=mark-packet chain=forward comment="Fin to p1" disabled=no \
new-packet-mark=p1 packet-size=0-256 passthrough=no protocol=tcp \
tcp-flags=fin
add action=mark-packet chain=forward comment="Syn to p1" disabled=no \
new-packet-mark=p1 packet-size=0-256 passthrough=no protocol=tcp \
tcp-flags=syn
add action=mark-connection chain=forward comment="Mark p2p connections first" \
disabled=no new-connection-mark=p2p_conn p2p=all-p2p passthrough=yes
add action=mark-connection chain=forward comment=\
"Mark PS3 as p1 with PASSTHROUGH" disabled=no new-connection-mark=PS3 \
passthrough=yes port=5223 protocol=tcp
add action=mark-connection chain=forward comment=\
"Mark PS3 as p1 with PASSTHROUGH" disabled=no new-connection-mark=PS3 \
passthrough=yes port=3479 protocol=udp
add action=mark-connection chain=forward comment=\
"Mark PS3 as p1 with PASSTHROUGH" disabled=no new-connection-mark=PS3 \
passthrough=yes port=3658 protocol=udp
add action=mark-connection chain=forward comment=\
"Mark PS3 as p1 with PASSTHROUGH" disabled=no new-connection-mark=PS3 \
passthrough=yes port=3478 protocol=udp
add action=mark-packet chain=forward comment=\
"Mark PS3 as p1 with NO PASSTHROUGH" connection-mark=PS3 disabled=no \
new-packet-mark=p1 passthrough=no protocol=tcp
add action=mark-packet chain=forward comment="Any identifiable P2P is set at p\
8 with NO PASSTHROUGH. This is the lowest priority we can configure" \
connection-mark=p2p_conn disabled=no new-packet-mark=p8 passthrough=no
add action=mark-packet chain=forward comment=\
"Mark XBox as p1 with NO PASSTHROUGH" disabled=no new-packet-mark=p1 \
passthrough=no port=3074 protocol=tcp
add action=mark-packet chain=forward comment=\
"Mark XBox as p1 with NO PASSTHROUGH" disabled=no new-packet-mark=p1 \
passthrough=no port=3074 protocol=udp
add action=mark-packet chain=forward comment=\
"Mark XBox as p1 with NO PASSTHROUGH" disabled=no new-packet-mark=p1 \
passthrough=no port=88 protocol=udp
add action=mark-packet chain=forward comment=\
"Mark Wii as p1 with NO PASSTHROUGH" disabled=no new-packet-mark=p1 \
passthrough=no port=28910 protocol=tcp
add action=mark-packet chain=forward comment=\
"Mark Wii as p1 with NO PASSTHROUGH" disabled=no new-packet-mark=p1 \
passthrough=no port=29900-29901 protocol=tcp
add action=mark-packet chain=forward comment=\
"Mark Wii as p1 with NO PASSTHROUGH" disabled=no new-packet-mark=p1 \
passthrough=no port=28920 protocol=tcp
add action=mark-connection chain=forward comment=\
"Mark DNS as p1 with NO PASSTHROUGH" disabled=no new-connection-mark=DNS \
passthrough=yes port=53 protocol=tcp
add action=mark-connection chain=forward comment=\
"Mark DNS as p1 with NO PASSTHROUGH" disabled=no new-connection-mark=DNS \
passthrough=yes port=53 protocol=udp
add action=mark-packet chain=forward comment=\
"Mark DNS as p1 with NO PASSTHROUGH" connection-mark=DNS disabled=no \
new-packet-mark=p1 passthrough=no
add action=mark-connection chain=forward comment="This captures some streaming\
\_video, such as most google video, cnn and some others" disabled=no \
layer7-protocol=video_http new-connection-mark=video passthrough=yes
add action=mark-packet chain=forward comment="How we handle qos for streams is\
\_defined here. currently, it is set to p5" connection-mark=video \
disabled=no new-packet-mark=p5 passthrough=no
add action=mark-packet chain=forward comment=\
"This will match Hulu and similar streams - p5 NO PASSTHROUGH" disabled=\
no new-packet-mark=p5 passthrough=no port=1935 protocol=tcp
add action=mark-packet chain=forward comment="This will match the ms-streaming\
\_protocol used by several online tv stations - p5 NO PASSTHROUGH" \
disabled=no new-packet-mark=p5 passthrough=no port=1755 protocol=tcp
add action=mark-packet chain=forward comment="This will match the RTSP streami\
ng protocol used by several online tv stations - p5 NO PASSTHROUGH" \
disabled=no new-packet-mark=p5 passthrough=no port=554 protocol=tcp
add action=mark-packet chain=forward comment=\
"VOIP - SIP - Set for p2 with NO PASSTHROUGH" disabled=no \
new-packet-mark=p2 passthrough=no port=5060-5061 protocol=tcp
add action=mark-packet chain=forward comment=\
"VOIP - SIP - Set for p2 with NO PASSTHROUGH" disabled=no \
new-packet-mark=p2 passthrough=no port=5060-5061 protocol=udp
add action=mark-packet chain=forward comment="ICMP is p2 NO PASSTHROUGH" \
disabled=no new-packet-mark=p2 passthrough=no protocol=icmp
add action=mark-connection chain=forward comment=\
"VOIP - mark DSCP 46 with voip connection mark" disabled=no dscp=46 \
new-connection-mark=voip passthrough=yes
add action=mark-packet chain=forward comment=\
"For the voip connection mark - set to p1 with NO PASSTHROUGH" \
connection-mark=voip disabled=no new-packet-mark=p1 passthrough=no
add action=mark-packet chain=forward comment=\
"Pop3 - Set at p3 with NO PASSTHROUGH" disabled=no new-packet-mark=p3 \
passthrough=no port=110 protocol=tcp
add action=mark-packet chain=forward comment=\
"SMTP traffic will be p3 by default NO PASSTHROUGH " disabled=no \
new-packet-mark=p3 passthrough=no port=25 protocol=tcp
add action=mark-packet chain=forward comment="NTP is set at p1. It does not ta\
ke much bandwidth, so nearly any priority above 3 or so should be ok" \
disabled=no new-packet-mark=p1 passthrough=no port=123 protocol=udp
add action=mark-connection chain=forward comment=\
"Secure SMTP - Set at p3 with NO PASSTHROUGH" disabled=no \
new-connection-mark=Mail passthrough=yes port=465 protocol=tcp
add action=mark-connection chain=forward comment=\
"Secure SMTP - Set at p3 with NO PASSTHROUGH" disabled=no \
new-connection-mark=Mail passthrough=yes port=587 protocol=tcp
add action=mark-connection chain=forward comment=\
"Secure IMAP- Set at p3 with NO PASSTHROUGH" disabled=no \
new-connection-mark=Mail passthrough=yes port=485 protocol=tcp
add action=mark-connection chain=forward comment=\
"IMAP over SSL- Set at p3 with NO PASSTHROUGH" disabled=no \
new-connection-mark=Mail passthrough=yes port=993 protocol=tcp
add action=mark-connection chain=forward comment=\
"IMAP - Set at p3 with NO PASSTHROUGH" disabled=no new-connection-mark=\
Mail passthrough=yes port=143 protocol=tcp
add action=mark-connection chain=forward comment=\
"POP3 over SSL- Set at p3 with NO PASSTHROUGH" disabled=no \
new-connection-mark=Mail passthrough=yes port=995 protocol=tcp
add action=mark-packet chain=forward comment=\
"POP3 over SSL- Set at p3 with NO PASSTHROUGH" connection-mark=Mail \
disabled=no new-packet-mark=p3 passthrough=no
add action=mark-packet chain=forward comment=\
"NNTP is set at p7, NO PASSTHROUGH" disabled=no new-packet-mark=p7 \
passthrough=no port=119 protocol=tcp
add action=mark-packet chain=forward comment=\
"NNTP - Alternate port - is set at p7, NO PASSTHROUGH" disabled=no \
new-packet-mark=p7 passthrough=no port=433 protocol=tcp
add action=mark-packet chain=forward comment="SNMP set at p4 NO PASSTHROUGH" \
disabled=no new-packet-mark=p4 passthrough=no port=161 protocol=udp
add action=mark-packet chain=forward comment=\
"IPSEC-ESP - Set for p3 with NO PASSTHROUGH" disabled=no new-packet-mark=\
p3 passthrough=no protocol=ipsec-esp
add action=mark-packet chain=forward comment=\
"IPSEC-AH - Set for p3 with NO PASSTHROUGH" disabled=no new-packet-mark=\
p3 passthrough=no protocol=ipsec-ah
add action=mark-packet chain=forward comment=\
"RDP - Set for p3 with NO PASSTHROUGH" disabled=no new-packet-mark=p3 \
passthrough=no port=3389 protocol=tcp
add action=mark-packet chain=forward comment="SSH p2 NO PASSTHROUGH" \
disabled=no new-packet-mark=p2 passthrough=no port=22 protocol=tcp
add action=mark-packet chain=forward comment="telnet p2 NO PASSTHROUGH" \
disabled=no new-packet-mark=p2 passthrough=no port=23 protocol=tcp
add action=mark-packet chain=forward comment="WINBOX p1 NO PASSTHROUGH" \
disabled=no new-packet-mark=p1 passthrough=no port=8291 protocol=tcp
add action=mark-connection chain=forward comment="For a single IP making over \
50 connections OUTBOUND - Jump to the chain that will process that traffic\
\_- will be HTTPS or some unidentified protocol - MOST LIKELY P2P or torre\
nts" connection-limit=50,32 connection-state=new disabled=no dst-port=\
80,443 new-connection-mark=HighConnectRates passthrough=yes protocol=tcp \
src-address-list=QOSCustomerIPs
add action=return chain=HighConnectRate comment="Do not count connections for \
users in the DoNotTestConnectionCounts address list" disabled=no \
src-address-list=DoNotTestConnectionCounts
add action=add-src-to-address-list address-list=HighConnectionIP \
address-list-timeout=1h chain=HighConnectRate comment="For anyone who is m\
aking more connections than we want, we will grab their IP for 1 hour. " \
disabled=no src-address-list=QOSCustomerIPs
add action=mark-packet chain=HighConnectRate comment="Set users making high co\
nnection counts on HTTPS port, we will change to p7 for these users" \
disabled=no new-packet-mark=p7 passthrough=no
add action=jump chain=forward connection-mark=HighConnectRates disabled=no \
jump-target=HighConnectRate
add action=mark-connection chain=forward comment="Mark HTTP/S connections" \
disabled=no new-connection-mark=HTTP/S passthrough=yes port=80,443 \
protocol=tcp
add action=mark-packet chain=forward comment=\
"bytes 0-1000000 will be treated as p3" connection-bytes=0-1000000 \
connection-mark=HTTP/S disabled=no new-packet-mark=p3 passthrough=no
add action=mark-packet chain=forward comment=\
"bytes 1000001-5000000 will be treated as p4" connection-bytes=\
1000001-5000000 connection-mark=HTTP/S disabled=no new-packet-mark=p4 \
passthrough=no
add action=mark-packet chain=forward comment=\
"Remaining bytes per flow are treated as p5" connection-bytes=5000001-0 \
connection-mark=HTTP/S disabled=no new-packet-mark=p5 passthrough=no
add action=mark-packet chain=forward comment="Set remaining SSL to p1" \
disabled=no new-packet-mark=p3 passthrough=no port=443 protocol=tcp
add action=mark-packet chain=forward comment=\
"Set remaining UDP small packets to p1" disabled=no new-packet-mark=p3 \
packet-size=0-800 passthrough=no protocol=udp
add action=mark-packet chain=forward comment=\
"Set remaining UDP packets to p5" disabled=no new-packet-mark=p5 \
passthrough=no protocol=udp
add action=mark-packet chain=forward comment="Everything else TCP" disabled=\
no new-packet-mark=p5 passthrough=no protocol=tcp
add action=mark-packet chain=forward comment="Everything else UDP" disabled=\
no new-packet-mark=p5 passthrough=no protocol=udp
add action=mark-packet chain=forward comment="Everything else" disabled=no \
new-packet-mark=p5 passthrough=no
/ip firewall nat
add action=dst-nat chain=dstnat comment="7 to Art's computer" disabled=no \
dst-port=7 in-interface=ether1-gateway protocol=udp to-addresses=\
192.168.1.109 to-ports=7
add action=dst-nat chain=dstnat comment="9 to Art's computer" disabled=no \
dst-port=9 in-interface=ether1-gateway protocol=udp to-addresses=\
192.168.1.109 to-ports=9
add action=dst-nat chain=dstnat comment="22 to Mom's computer" disabled=no \
dst-port=22 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.97 to-ports=22
add action=dst-nat chain=dstnat comment="53 to Mom's computer" disabled=no \
dst-port=53 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.97 to-ports=22
add action=dst-nat chain=dstnat comment="54 to Mom's computer" disabled=no \
dst-port=54 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.97 to-ports=22
add action=dst-nat chain=dstnat comment="123 to Mom's computer" disabled=no \
dst-port=123 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.97 to-ports=22
add action=dst-nat chain=dstnat comment="407 to Mom's computer" disabled=no \
dst-port=407 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.98 to-ports=407
add action=dst-nat chain=dstnat comment="1280 to 192.168.1.1" disabled=no \
dst-port=1280 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.1 to-ports=80
add action=dst-nat chain=dstnat comment="1281 to 192.168.1.20" disabled=no \
dst-port=1281 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.20 to-ports=80
add action=dst-nat chain=dstnat comment="1282 to 192.168.1.21" disabled=no \
dst-port=1282 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.21 to-ports=80
add action=dst-nat chain=dstnat comment="1290 to 192.168.88.1" disabled=no \
dst-port=1290 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.88.1 to-ports=80
add action=dst-nat chain=dstnat comment="3283 to Mom's computer" disabled=no \
dst-port=3283 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.98 to-ports=3283
add action=dst-nat chain=dstnat comment="3283 to Mom's computer" disabled=no \
dst-port=3283 in-interface=ether1-gateway protocol=udp to-addresses=\
192.168.1.98 to-ports=3283
add action=dst-nat chain=dstnat comment="5900 to Mom's computer" disabled=no \
dst-port=5900 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.98 to-ports=5900
add action=dst-nat chain=dstnat comment="5900 to Mom's computer" disabled=no \
dst-port=5900 in-interface=ether1-gateway protocol=udp to-addresses=\
192.168.1.98 to-ports=5900
add action=dst-nat chain=dstnat comment="3284 to Mom's computer" disabled=no \
dst-port=3284 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.97 to-ports=3283
add action=dst-nat chain=dstnat comment="3284 to Mom's computer" disabled=no \
dst-port=3284 in-interface=ether1-gateway protocol=udp to-addresses=\
192.168.1.97 to-ports=3283
add action=dst-nat chain=dstnat comment="5901 to Mom's computer" disabled=no \
dst-port=5901 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.97 to-ports=5900
add action=dst-nat chain=dstnat comment="5901 to Mom's computer" disabled=no \
dst-port=5901 in-interface=ether1-gateway protocol=udp to-addresses=\
192.168.1.97 to-ports=5900
add action=masquerade chain=srcnat comment="Added by webbox" disabled=no \
out-interface=ether1-gateway
add action=dst-nat chain=dstnat comment="22 to Mom's computer" disabled=no \
dst-port=22 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.98 to-ports=22
add action=dst-nat chain=dstnat comment="53 to Mom's computer" disabled=no \
dst-port=53 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.98 to-ports=22
add action=dst-nat chain=dstnat comment="407 to Mom's computer" disabled=no \
dst-port=407 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.98 to-ports=407
add action=dst-nat chain=dstnat comment="1281 to 192.168.1.20" disabled=no \
dst-port=1281 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.20 to-ports=80
add action=dst-nat chain=dstnat comment="1280 to 192.168.1.1" disabled=no \
dst-port=1280 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.1 to-ports=80
add action=dst-nat chain=dstnat comment="3283 to Mom's computer" disabled=no \
dst-port=3283 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.98 to-ports=3283
add action=dst-nat chain=dstnat comment="3283 to Mom's computer" disabled=no \
dst-port=3283 in-interface=ether1-gateway protocol=udp to-addresses=\
192.168.1.98 to-ports=3283
add action=dst-nat chain=dstnat comment="5900 to Mom's computer" disabled=no \
dst-port=5900 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.98 to-ports=5900
add action=dst-nat chain=dstnat comment="5900 to Mom's computer" disabled=no \
dst-port=5900 in-interface=ether1-gateway protocol=udp to-addresses=\
192.168.1.98 to-ports=5900
add action=dst-nat chain=dstnat comment="3284 to Mom's computer" disabled=no \
dst-port=3284 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.97 to-ports=3283
add action=dst-nat chain=dstnat comment="3284 to Mom's computer" disabled=no \
dst-port=3284 in-interface=ether1-gateway protocol=udp to-addresses=\
192.168.1.97 to-ports=3283
add action=dst-nat chain=dstnat comment="5901 to Mom's computer" disabled=no \
dst-port=5901 in-interface=ether1-gateway protocol=tcp to-addresses=\
192.168.1.97 to-ports=5900
add action=dst-nat chain=dstnat comment="5901 to Mom's computer" disabled=no \
dst-port=5901 in-interface=ether1-gateway protocol=udp to-addresses=\
192.168.1.97 to-ports=5900
add action=masquerade chain=srcnat comment="Added by webbox" disabled=no \
out-interface=ether1-gateway
/ip firewall service-port
set ftp disabled=no ports=21
set tftp disabled=no ports=69
set irc disabled=no ports=6667
set h323 disabled=no
set sip disabled=no ports=5060,5061
set pptp disabled=no

Please post the output of "/ip firewall export" and confirm that you're sending traffic to udp/7.

Posted

You cannot be sending traffic to the PC's MAC address as it isn't part of your local network. The MAC address may be embedded in the payload, but it most certainly isn't embedded in the layer 2 header.

Well all I can say is that I seem to be able to. I don't know how it's working, but it does. If I send WOL packets with the app shown in the pic below (or from the virtual PC on my Mac here using the PC based app, either app works), and from Venezuela send WOL packets to the public address of the router in NY, and I send with the MAC of the target the computer (the app needs both the IP address and the MAC address), the packet gets to the computer on the LAN in NY as evidenced by the app on that computer saying it received a WOL packet. I can watch the remote PC's screen and my own screen at the same time and watch as I send the packet and it's received on the other end. I can also watch the router with WinBox and see the WOL packets transverse the router as well. If I send to the wrong MAC address the packet doesn't go to the target machine even though I have a port based DstNat that should take the packet received by the router on it's WAN interface on port 7 or 9 and send it to the target machine. The MAC address sent in the WOL packet from Venezuela to NY matters.

For a test I should change the DstNat to another machine but still send with the target PC's MAC address and see if it still gets to the target machine. It could be all MAC address based at that point.

As for me, I would like to see "your" /interface ethernet switch print please.

# apr/14/2011 15:26:42 by RouterOS 5.1
/interface ethernet switch port
[...]

Fail and not please

These forward all traffic to udp/7 and udp/9 to 192.168.1.109. That means that packets sent from NY to udp/7 or udp/9 with a destination IP address of the WAN interface on the Venezuela router will have their destination IP address rewritten to 192.168.1.109, and will be in the forward chain (and never in the input chain, ever). Incidentally, another way to think about the input chain is that once a packet is in it, IT WILL NEVER LEAVE THE ROUTER AGAIN because the router will consume it.

According to your exported firewall filters there are no filters in the forward chain. The default is to pass traffic. Thus, the packets are forwarded to 192.168.1.109 as specified by your configured firewall policy.

Add this: Then test WOL. It will fail.

The MAC matters, but not in the way you think. MAC addresses are used to send packets on layer 2. It is literally impossible to send a packet from NY to Venezuela by MAC address - unless you have a layer 2 circuit that directly connects the two points without ANY routers in the way. The MAC address matters because it is in the WOL payload. Please re-read the wikipedia link I referred to in my original post in this thread. The MAC address is contained in the actual payload of the packet, not in the address header while on route to the router 192.168.1.109 is behind.

Code: Select all

/ip firewall nat
add action=dst-nat chain=dstnat comment="7 to Art's computer" disabled=no \
dst-port=7 in-interface=ether1-gateway protocol=udp to-addresses=\
192.168.1.109 to-ports=7
add action=dst-nat chain=dstnat comment="9 to Art's computer" disabled=no \
dst-port=9 in-interface=ether1-gateway protocol=udp to-addresses=\
192.168.1.109 to-ports=9

These forward all traffic to udp/7 and udp/9 to 192.168.1.109. That means that packets sent from NY to udp/7 or udp/9 with a destination IP address of the WAN interface on the Venezuela router will have their destination IP address rewritten to 192.168.1.109, and will be in the forward chain (and never in the input chain, ever). Incidentally, another way to think about the input chain is that once a packet is in it, IT WILL NEVER LEAVE THE ROUTER AGAIN because the router will consume it.

Fewi - Thanks so much for taking the time to reply! Though I think you have it backwards, the router in question is in NY, the target machine is behind that router in NY, and I'm sending the WOL packets from Venezuela.

The router here in Venezuela doesn't have any rules for ports 7 and 9, it's just passing them right on out.

The router in NY has the DstNat but I'm wondering how much that even does anything because if I send a WOL packet to the router in NY on port 7 (there's a DstNat rule for that) but I use the MAC address of another machine (not the one with 192.168.1.109 which is where the DstNat rule points) the packet doesn't get to 192.168.1.109. That seems counter intuitive.

Greg

OK, I had NY and Venezuela swapped.

What you're describing isn't counterintuitive at all. Again, the MAC address is embedded in the payload of the WOL packet. When you send to a different MAC a different MAC is embedded in the payload. The packet is sent to 192.168.1.109, but that host doesn't listen because its MAC address isn't embedded in the payload, so it ignores it since it isn't a WOL packet for it. Usually WOL packets are sent to ALL hosts on a network. You wouldn't want that packet to wake up all hosts, so hosts that have a MAC address that isn't embedded in the payload discard it. That's by design.
If you were to use a packet analyzer such as Wireshark you could possibly see the packet arrive on the interface, unless the NIC discards it without ever passing it to the OS. You would be able to see the packet leave the router capturing traffic on the router's LAN interface.

Add this:

Code: Select all

/ip firewall filter
add chain=forward protocol=udp dst-port=7,9 action=drop

Then test WOL. It will fail.

Yes! It does. But how come this doesn't stop the WOL:
It's the same rule in the input. The packet is sent to the router's IP address and port 7. The WOL packet contains the MAC address of a machine on the router's lan, but as you said, that's in the payload of the WOL and not in the header. How come the router doesn't see the WOL packet as something destined for it's port 7? It seems to know it's for something it should route for, and hence in the forward chain you can process the WOL packet.

I also did some more testing and found out the DstNat rule does forward the packet to 192.168.1.109 regardless of the MAC address contained in the payload of the WOL packet, contrary to what I thought I had seen in previous testing.

Greg

It's the same rule in the input. The packet is sent to the router's IP address and port 7. The WOL packet contains the MAC address of a machine on the router's lan, but as you said, that's in the payload of the WOL and not in the header. How come the router doesn't see the WOL packet as something destined for it's port 7? It seems to know it's for something it should route for, and hence in the forward chain you can process the WOL packet.

I don't know how else to explain to you how the chains work. I've tried three different approaches now.

You have a destination NAT rule. That destination NAT rule tells the router to look for new connections going to udp/7 and udp/9 coming into the router's WAN port. It then tells the router to rewrite the destination IP address of those packets to 192.168.1.109.

A packet comes in that matches (udp/7 or udp/9 coming in via the WAN port) and it rewrites the destination IP address to 192.168.1.109 as per your rule. The router then looks at the destination IP address of the packet to decide what to do with it, and where to put it. "Ah ha!", it thinks. "That IP address isn't me. But I know how to get to that IP address - I send it out the interface on that network!". So it puts the packet into the forward chain, because that's where packets going through the router go. This packet goes through the router - it is coming from the WAN and going to a host behind the router.

The forward chain and input chain are parallel. The forward chain contains all packets that go through the router AFTER the router has applied destination NAT to the packets. The input chain contains all packets that go TO the router after the router has applied destination NAT to the packets. Your packet's IP address goes through the router after destination NAT. Therefore, the packet is always in the forward chain, and never in the input chain.

I don't know how to be more clear than that.
Of course it does. You're telling it to, with your destination NAT rule. You're literally telling the router "whenever something comes in via the WAN interface for udp/7 or udp/9 send it to 192.168.1.109", so the router does as it is told.

You _may_ be able to destination NAT to 192.168.1.0 or 192.168.1.255 (your subnet or broadcast address, assuming you're using 192.168.1.0/24) instead of 192.168.1.109. Destination NAT to the subnet address would be an SBR (subnet directed broadcast), which is how WOL is usually propagated across layer 3 boundaries. Destination NAT to the broadcast address would just be a normal broadcast. Either should be delivered to all hosts on the subnet (just like a locally generated WOL packet) and whichever host sees its own MAC in the payload would process it. But that's theoretical. I've never tried either with RouterOS, so it may not work. Worth a shot though if you need to reach more than one WOL host given that it takes just editing your relevant destination NAT rules to try it out.

Exellently put. I enjoyed reading it! Greg is confused about the order of the chains through which packets travel. It seems he thinks it will hit the input chain first because packets coming from the WAN travel to the public address on the router.

And the reason why it does not hit the input chain first is because the NAT table rewrites the (destination) IP address. The rewritten ip address is no longer the public ip on the router (so the packet will NOT got to the input chain) but the private ip on a host. Since the address is on a host, the packet goes to the forward chain.

That's what I make of it:)

this makes exellent reading: http://www.frozentux.net/documents/iptables-tutorial/

Precisely.

It's the same rule in the input. The packet is sent to the router's IP address and port 7. The WOL packet contains the MAC address of a machine on the router's lan, but as you said, that's in the payload of the WOL and not in the header. How come the router doesn't see the WOL packet as something destined for it's port 7? It seems to know it's for something it should route for, and hence in the forward chain you can process the WOL packet.

I don't know how else to explain to you how the chains work. I've tried three different approaches now.

You have a destination NAT rule. That destination NAT rule tells the router to look for new connections going to udp/7 and udp/9 coming into the router's WAN port. It then tells the router to rewrite the destination IP address of those packets to 192.168.1.109.

A packet comes in that matches (udp/7 or udp/9 coming in via the WAN port) and it rewrites the destination IP address to 192.168.1.109 as per your rule. The router then looks at the destination IP address of the packet to decide what to do with it, and where to put it. "Ah ha!", it thinks. "That IP address isn't me. But I know how to get to that IP address - I send it out the interface on that network!". So it puts the packet into the forward chain, because that's where packets going through the router go. This packet goes through the router - it is coming from the WAN and going to a host behind the router.

The forward chain and input chain are parallel. The forward chain contains all packets that go through the router AFTER the router has applied destination NAT to the packets. The input chain contains all packets that go TO the router after the router has applied destination NAT to the packets. Your packet's IP address goes through the router after destination NAT. Therefore, the packet is always in the forward chain, and never in the input chain.

I don't know how to be more clear than that.

Code: Select all

I also did some more testing and found out the DstNat rule does forward the packet to 192.168.1.109 regardless of the MAC address contained in the payload of the WOL packet, contrary to what I thought I had seen in previous testing.

Of course it does. You're telling it to, with your destination NAT rule. You're literally telling the router "whenever something comes in via the WAN interface for udp/7 or udp/9 send it to 192.168.1.109", so the router does as it is told.

You _may_ be able to destination NAT to 192.168.1.0 or 192.168.1.255 (your subnet or broadcast address, assuming you're using 192.168.1.0/24) instead of 192.168.1.109. Destination NAT to the subnet address would be an SBR (subnet directed broadcast), which is how WOL is usually propagated across layer 3 boundaries. Destination NAT to the broadcast address would just be a normal broadcast. Either should be delivered to all hosts on the subnet (just like a locally generated WOL packet) and whichever host sees its own MAC in the payload would process it. But that's theoretical. I've never tried either with RouterOS, so it may not work. Worth a shot though if you need to reach more than one WOL host given that it takes just editing your relevant destination NAT rules to try it out.

I get it now! Thanks so much! Sorry it took me so long! The third time was the charm!

Greg

No worries, glad I found a good way to phrase it.

If you do end up experimenting with NATing to the subnet or broadcast address to flood WOL packets to all hosts on the network behind the router please post your results here; I am curious if it will work, but too lazy to lab it up myself.

No worries, glad I found a good way to phrase it.

If you do end up experimenting with NATing to the subnet or broadcast address to flood WOL packets to all hosts on the network behind the router please post your results here; I am curious if it will work, but too lazy to lab it up myself.

Fewi - Thanks for bearing with me! Can I buy you a beer? : - )

I believe I have tried the broadcast and it worked in all the testing I did in the past day, but I was in such a swamp of misunderstanding I want to repeat the experiment before I say "yes, it works". I'm doing it now. I'll post the results.

Greg

No worries, glad I found a good way to phrase it.

If you do end up experimenting with NATing to the subnet or broadcast address to flood WOL packets to all hosts on the network behind the router please post your results here; I am curious if it will work, but too lazy to lab it up myself.

Fewi - I tried changing the DstNat rule to forward to 192.168.1.255 but could never get it to work, I couldn't get the target PC to indicate a received WOL packet.

But I did learn something interesting along the way. When one changes the DstNat rule to forward to a broadcast address the packet then no longer travels the Forward chain but instead travels the Input chain. That would indicate to me that the packet is headed towards one of the router's own interfaces. Maybe that's why the target PC never saw the packet.

Greg

Thanks for testing. That sorta makes sense.