"Router Solicitation" As A Rules Order Test?

Hi all,

I am new to fire walls and for a day now I have been reading and learning about RULES and where they should be.. ALOT of trial and error !!! I was reading from a link givin to me and for the life of me cant remember what link it was and im sorry for that.... anyways this link was talking about rules and order of rules and IF I inturpeted it right the rules said I could do a "Router Solicitation" to see if the rules worked that I have.
Well let me tell you.... LOL this is exactly what I did following these rules....
Once you have the DHCP server IP address, you can configure your rules.

= = = = = = = = = = =
Rule #1:
Description: DHCP In/Out
Protocol: UDP
Direction: Both
Local End Port:68
Application: ANY (or your DHCP program)
Remote End Port: 67
Remote Address: DHCP Server IP
Rule Valid: Always
Action: Permit
Logging: None
= = = = = = = = = = =
Rule #2:
Description: DHCP
Protocol: UDP
Direction: Outgoing
Local End Port:68
Application: ANY (or your DHCP program)
Remote End Port: 67
Remote Address: 255.255.255.255
Rule Valid: Always
Action: Permit
Logging: None
= = = = = = = = = = =
After this try to release and renew your IP with Rule Learning thing on just to make sure the rules work

Is this a viable test? and if so maybe then I can decifer all of what I got on my Firewall log.
I can make sence of it somewhat and every last thing in the logg was BLOCKED from TCP to UDP, ICMP, NETBIOS and even LAST RULE BLOCK ALL!!!

My blocks came in the order of this maybe someone can look and give me some input as to what i am seeing and if order looks right... I am not sure this is even a valid test
Regards,
FireDancer

 

opps sorry wrong gif im reposting screen shot now

 

You should have just added to your previous thread...
Previous Thread

That is one communication you should block, and I have not known a situation you need to allow it. If you use a router, and your having connection problems with your router you might allow it as a test, however you shouldn't need to. If you want you can even make a special rule to block it, and not have the rule logging so it doesn't fill your logs.

BTW, under administration, in the advanced area where you can edit your rules you should goto your Miscellaneous tab, and uncheck Log suspicous packets as this will fill your logs full of junk which is basically timed out communications for the most part.

 

BlitzenZues,

Disabled "log suspicous packets" thanks for the info..
was this a viable test or not? did it actually show that rules worked as it was stated in the post?

Best Regards,

FireDancer

 

Well in rule based firewalls they are processed from the beginning to the end, but the logs don't usually show it unless you have your allow rules logging. The first rule that matches will stop the filtering process for that packet.

If you want to test certain rules, you can make all the rules that would be effected by the communication logging.

Here are two examples:

[_] Allow icmp 8 inbound
[x] Allow icmp 0 outbound
[x] Block all icmp
-- You cannot be pinged, and the last rule would have logged the inbound icmp 8 communication.

[x] Allow icmp 8 inbound
[x] Allow icmp 0 outbound
[x] Block all icmp
- You can be pinged, and the first rule would have logged the inbound icmp 8 communication.