Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 33 replies
  • Subscribers 2 subscribers
  • Views 55657 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

UTM 9.1 cleanup

FormerMember
FormerMember
I'm looking to cleanup or check my rules I have set just to be sure things are running smooth.   

I've got a p2p client that currently is spamming the firewall pretty heavily.  Mostly what I see in the firewall log is source outside address udp's that are chosing the modem external address.

I'm under the assumption these are the addresses or connections on the p2p client looking for the outside in traffic return.   However, because these do not have a source inside address, what is the safe way of handling these without opening everything up?


This thread was automatically locked due to age.
Parents
  • 0
    The info you posted was correct.  It was confusing that I explained things the way I did.  I should have just said that you don't see packets there that are allowed/dropped/rejected unless the Firewall rule allowing/dropping/rejecting them has logging enabled.  All Default Drops are logged.

    As dilandau implied, you don't need a Firewall rule for inbound traffic that is a response to a request sent from the UTM.  It is a "stateful" firewall - it uses a connection tracker to automatically allow responses to requests sent from it.

    By the same token, for traffic that came in from a public client via a DNAT, you don't need a separate Firewall rule to allow the response back to the public client.

    Cheers - Bob
Reply
  • 0
    The info you posted was correct.  It was confusing that I explained things the way I did.  I should have just said that you don't see packets there that are allowed/dropped/rejected unless the Firewall rule allowing/dropping/rejecting them has logging enabled.  All Default Drops are logged.

    As dilandau implied, you don't need a Firewall rule for inbound traffic that is a response to a request sent from the UTM.  It is a "stateful" firewall - it uses a connection tracker to automatically allow responses to requests sent from it.

    By the same token, for traffic that came in from a public client via a DNAT, you don't need a separate Firewall rule to allow the response back to the public client.

    Cheers - Bob
Children
  • FormerMember
    0 FormerMember in reply to BAlfson
    The info you posted was correct.  It was confusing that I explained things the way I did.  I should have just said that you don't see packets there that are allowed/dropped/rejected unless the Firewall rule allowing/dropping/rejecting them has logging enabled.  All Default Drops are logged.

    As dilandau implied, you don't need a Firewall rule for inbound traffic that is a response to a request sent from the UTM.  It is a "stateful" firewall - it uses a connection tracker to automatically allow responses to requests sent from it.

    By the same token, for traffic that came in from a public client via a DNAT, you don't need a separate Firewall rule to allow the response back to the public client.

    Cheers - Bob


    I made a quote as an answer to this on my previous post.

    I've got logging enabled on all my firewall rules and the DNAT's, so I can see what is going on.

    So I guess I will need some assistance then going through the rules again to determine the inbound rules that are not required.