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
  • Your DNAT and Firewall rule 2 for "vuze IN" are incorrect.
    DNAT should be:
    traffic selector: ANY -> vuze IN -> External WAN (Address)
    change destination to: TURBO

    In Firewall rules delete rule 2 then rule 4 should allow the traffic in.
  • FormerMember
    0 FormerMember in reply to dilandau
    In following the requested changes, I have attached the firewall log of what I have now.
  • In following the requested changes, I have attached the firewall log of what I have now.

    Is it working now or not? Logs seem to conclude it is,  if not may be problem with your service definitions. 

    I haven't used vuze in awhile but you should only need one service if you use the tcp/udp option.
    example:
    source:1:65535
    destination: 6881 (or whatever is set in the client)

    This confuses me, because there is a service (protocol group) in the DNAT for Vuze.   Am I not suppose to have this group also then?

    Edit: Thought about this for a bit, are you only talking about the endpoint destination?


    Yes, the final destination cannot be a network.
Reply
  • In following the requested changes, I have attached the firewall log of what I have now.

    Is it working now or not? Logs seem to conclude it is,  if not may be problem with your service definitions. 

    I haven't used vuze in awhile but you should only need one service if you use the tcp/udp option.
    example:
    source:1:65535
    destination: 6881 (or whatever is set in the client)

    This confuses me, because there is a service (protocol group) in the DNAT for Vuze.   Am I not suppose to have this group also then?

    Edit: Thought about this for a bit, are you only talking about the endpoint destination?


    Yes, the final destination cannot be a network.
Children
  • FormerMember
    0 FormerMember in reply to dilandau
    Is it working now or not? Logs seem to conclude it is,  if not may be problem with your service definitions. 

    I haven't used vuze in awhile but you should only need one service if you use the tcp/udp option.
    example:
    source:1:65535
    destination: 6881 (or whatever is set in the client)

    Yes, the final destination cannot be a network.


    Are the statements in the firewall supposed to be all green aside from red drops?  

    In looking at the sophos help it states that grey is a natting issue (cannot be determined).

    The program is behaving a bit strangely.  Uploads to one tracker is not occurring until after the file is completed.

    In answer to your port statement, I found your statement to be slightly off from what I'm seeing in the log (example log attached).  

    For Vuze, I am seeing a tcp packet from the tracker, and the tracker's port (2710).  Although this does not seem to affect the programs operation, I"m wondering how important that packet is.  Not all trackers seem to send a tcp, and they are not all on the same port.

    In addition, for doing in and out firewall rules, do you need to reverse the source and destination ports?  Or do those end up being the same?
    (screenshot attached)