I’m trying my first basic firewall set and I think I’m missing something here. When I make a request it seems that the connection is not getting established and then the firewall blocks the incoming packets. Here’s the rule set: (more or less copied from a post by @zerobyte ) The log will show that the blocked traffic is coming from an IPv6 IP on port 80 or 443 with my computer as the destination and it gets dropped.
What log? None of your rules have log option. Are there no other rules that drop packets, e.g. in the “raw” table?
What you post here looks OK, but it probably isn’t the full story…
Your rules do seem right. The only thing that stands out to me is that the RST flag is set on your example dropped packet.
I seem to have this vague impression that I saw some release notes specifying that IPv6 state tracking had some bugs fixed at one point. Try running the latest firmware and see if that changes anything.
One thing you may want to improve is something that was pointed out to me in an unrelated thread. The rule that allows outbound forwarding to the Internet (allow out-interface=ether1) will also allow a hairpin bouncing off of your router. I.e. - one of your neighbors could set their default GW (or some specific route) with your router’s WAN address as the next hop. In IPv6 this doesn’t grant any benefit to the neighbor because ROS doesn’t have any NAT functionality there, but in IPv4, it can happen.
The fix would be to add a condition: in-interface=!ether1
In IPv4, with NAT enabled, this would allow your neighbors to spoof your IP and do “interesting” things on the Internet while obscuring their origin. The packets’ source IP AND MAC address would be your router, and it would be very difficult to show that you were not the actual source of these connections unless someone went above and beyond, sniffing all traffic on the segment and correlating the naughty packets from you with identical naughty packets from some other person but with your router’s WAN interface MAC address.
Thanks zero, I tried it both ways the other day when I found an old post of yours, same issue either way. I was running 6.39.2, just upgraded to 6.40.1 but I’m still seeing the same thing.
Funny thing is it appears to work. If I goto ipv6-test.com it shows green a cross the board, but yet the router is logging all messages while the page loads. I’m not sure what is happening.
This is a bug that is also present in IPv4. However, its roots are in Linux.
When a session is closed the connection rule is deleted immediately after FIN ACK while in fact it should be kept for a few seconds.
So when a FIN/FIN ACK/RST sequence is seen, the RST is not matched by “established”.
I have a separate rule that matches RST packets:
add action=accept chain=forward protocol=tcp tcp-flags=fin
add action=accept chain=forward protocol=tcp tcp-flags=rst
(as you see, for FIN as well, as a FIN ACK can be re-transmitted when the ACK or RST has not been received)
Sending RST instead of ACK as the final reply after FIN/FIN ACK is a Microsoft bug. The RFC says an ACK has to be sent. RST is a nongraceful session end.
I started paying a bit more attention to the devices that were having this problem and noticed it’s only a couple computers in the entire office generating these RST packets. The biggest offender is the user thats the most technically challenged person in the building. He’s also the VP, go figure. I’m assuming these computers have some internal problems going on that I need to look at. The filters seem to work as expected on computers like mine.
Try adding those two rules above your block rule (but below the established/related rule) and see if that “solves” the problem.
They will not hurt. Even the best companies have those VPs…
Scratch that last post, that might just be working. I’m getting a small handful or RST’s, but nothing like I had before. Prior it was filling up the log screen pretty rapidly.
Keep an eye on the rules and check if they match traffic (counter increases).
The RST rule should match RST traffic, and if it is before the logging rule you should not see it being logged anymore.
Of course you should put/move the rules in the correct order, they are evaluated top to bottom.
Since I have the attention of a couple of smart people let me ask another question. The above rule is for our office. I’ll keep playing with that one, but here’s what I’ve got so far for my core routers. Can you guys critique these and tell me if they should protect the routers themselves?
I’m assuming these computers have some internal problems going on that I need to look at. The filters seem to work as expected on computers like mine.