UTM 9.1 cleanup

As dilandau notes, your first NAT rule did not follow Rule #4.  In addition, your second NAT rule is ineffective.  You must DNAT to a Host, DNS Host or an Availability Group, not a Group or Network.

Cheers - Bob

As dilandau notes, your first NAT rule did not follow Rule #4.  In addition, your second NAT rule is ineffective.  You must DNAT to a Host, DNS Host or an Availability Group, not a Group or Network.

Cheers - Bob

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?

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.

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)

Green => Allowed packet from a Firewall rule with 'Log traffic' selected
Grey => Redirected packet based on a NAT rule with 'Log initial packet' selected
Red => Blocked packet

It looks like you need a Firewall rule like 'Internal (Network) -> {1:65535→2710} -> Any : Allow'.

Cheers - Bob
PS Rather than posting screen shots of the Firewall Live Log, it's better to post the same lines from the full log file as that contains more detailed information.

Green => Allowed packet from a Firewall rule with 'Log traffic' selected
Grey => Redirected packet based on a NAT rule with 'Log initial packet' selected
Red => Blocked packet

It looks like you need a Firewall rule like 'Internal (Network) -> {1:65535→2710} -> Any : Allow'.

Cheers - Bob
PS Rather than posting screen shots of the Firewall Live Log, it's better to post the same lines from the full log file as that contains more detailed information.

On the firewall list when selecting the help option at the top, this is where I got the information previously quoted:

Direct from the help file below:

------------------

Open Live Log: This will open a pop-up window containing a real-time log of filtered packets, whose regularly updating display shows recent network activity. The background color indicates which action has been applied:

    Red: The packet was dropped.
    Yellow: The packet was rejected.
    Green: The packet was allowed.
    Gray: The action could not be determined.

The live log also contains information about which firewall rule caused a packet to be rejected. Such information is essential for rule debugging.

------------------

I already have the 2710, as previously stated I was doing an example to show it, so the current rules not showing the 2710 and the log showing the 2710 drop were examples only.

However the rule you've stated confuses me, as you've stated any address for the 2710 port, when it is only one tracker that I have that is using the port.  The other trackers are different ports, and it is only just this one tracker thus far that I'm seeing a tcp packet in the log.

Concerning that port, I have it in the rule 2 and 3 statements, just not screenshotted.

That aside, back to my earlier question, do I need to reverse the ports in the rules for inbound and outbound, or are those correct?

By full log, I'm assuming you mean the text only log from the reporting section?  (attached then)

Edit:  I guess I should also state that right now all of my downloads are showing yellow face icons, which state there is a NAT issue.

Software's quote:  "Means that the tracker is ok, you're connected to peers, but you don't have any remote connection.  You may have a NAT problem if your torrents stay on yellow status all the time."

They've been yellow since making the requested change.

Green => Allowed packet from a Firewall rule with 

It looks like you need a Firewall rule like 'Internal (Network) -> {1:65535→2710} -> Any : Allow'.

Yes as Bob points out if the tracker is using a different port you will need to allow the traffic out via a firewall rule or add the service to the web proxy.

The port the trackers use and your bittorrent clients listening port are two different things. It is only necessary to create a DNAT for your listening port as stated Port forwarding - VuzeWiki vuze only listens on one port. It is necessary to also create Firewall rules to allow traffic in/out of the network and to allow the connections to the trackers.

Yes as Bob points out if the tracker is using a different port you will need to allow the traffic out via a firewall rule or add the service to the web proxy.

The port the trackers use and your bittorrent clients listening port are two different things. It is only necessary to create a DNAT for your listening port as stated Port forwarding - VuzeWiki vuze only listens on one port. It is necessary to also create Firewall rules to allow traffic in/out of the network and to allow the connections to the trackers.

As stated, I have the tracker port in the firewall rule 2 & 3.  No, the 2710 is not in the DNAT.   Since people seem to be confused about my Example ONLY previously stated.....  (screenshots of the real rules I have below then)

I don't really understand any of your services with port 80, there should be no reason for them to be included in that group and to DNAT that traffic to TURBO. The port 80 services are to communicate with the trackers?  The web surfing group in Firewall rule 6 should allow that traffic out, may need to add a udp service to that group.

If the NAT check is failing do you have any other DNAT rules? You mention the listening port is in a firewall rule, but I haven't seen the corresponding DNAT? 

Anyways seems we are going in circles here let's focus on getting the NAT correct then move on to issues with the trackers. So I'll just post all the necessary rules you need to get it working.

I'll use 6881 as an example (change for whatever your listening port is must be above 1024). Note:Internet and "ANY" can be use interchangeably for source and destination.

Services:
Bittorrent IN:
Destination: 6881
Source: 1:65535
Type: TCP/UDP

Bittorrent OUT:
Destination: 1:65535
Source: 6881

(This rule is only neccessary for bittorrent traffic since the connection tracking doesn't automatically allow out the reply traffic)

DNAT:
Traffic Selector: Internet -> Bittorrent IN -> External Wan (Address)
Destination: TURBO

Firewall Rules:

Bittorrent:
Internet -> Bittorrent IN -> TURBO  (Or check Auto Firewall Rule in DNAT)

TURBO -> Bittorrent OUT -> Internet

Trackers:
If a tracker is using a specific port such as 2222 (if tracker is on port 80 or 8080 there is a built in http service you can use)
Create Service:
Destination: 2222
Source: 1:65535
Type: TCP/UDP or TCP or UDP

Firewall:
TURBO -> 2222 -> Internet (or create a dns or host definition for the specific tracker)

repeat for all trackers 

OR

create a firewall rule to allow services for your PC

TURBO -> ANY -> Internet