UTM 9.1 cleanup

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

Regarding the port 80 traffic with the trackers question you mentioned earlier, this was not a requirement, just a grouping to lower the number of rules for keeping it simple to determine the issues first before separating traffic.

Regarding the question for DNAT rules, yes I have 2 other DNAT rules that are currently OFF for troubleshooting this connection.

Regarding the listening port in a DNAT, now you have me confused as I had it in there but took it out, as there was a prior statement from someone that stated the tracker port was not needed in the DNAT, only the port of the Vuze software.....  So which is it?  Is the port needed in the DNAT for the tracker, yes or no?

From your list I have added the following:

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

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

create a firewall rule to allow services for your PC

TURBO -> ANY -> Internet

-----------

Per your recommendation after adding the above I tried disabling:

Bittorrent OUT:
Destination: 1:65535
Source: 6881

Since my port is 80 for Vuze, to let the Webservice rule take that, however for whatever reason the system started dropping packets all over the place when I did so.   So I reenabled the rule for now.   And yes, the webservice rule has tcp 80 and udp 80 in it.

Currently, after the above reenable, all of my downloads are showing NAT error.   The live log for the firewall is still showing the DNAT rule 1 in grey, aside from regular green traffic and the intermittent red drops in the live log.

After making the changes, I cleared the firewall report log.   I have attached the traffic after that point for review if needed.

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

Are you trying to use the web remote service is that why you have the port 80 traffic for the DNAT?

Please specifically state which services are for what, as the terminology is being mixed up for the Bittorrent listening port, trackers and other services.

Are you trying to use the web remote service is that why you have the port 80 traffic for the DNAT?

Please specifically state which services are for what, as the terminology is being mixed up for the Bittorrent listening port, trackers and other services.

No it is not the reason I have port 80 for the DNAT.   I've been following everyone's instructions here for the creation of the rules, and the DNAT was mentioned as needed for the firewall rule for the Vuze software.

No one up until this point has stated that the inbound is not necessary, regarding the "stateful firewall" statement.

I'm using port 80 on Vuze for ease of use, just so additional ports are not required.

Edit: Software Ports (Keep in mind that on these I have the others shut off when doing the current Vuze work, and they have remained off until at least the Vuze is working as it should, then I was going to proceed from there):

Vuze
Port 80 (for software)
Port 2710 (for only 1 tracker that is doing a tcp response)

FFXIV ARR (game)
UDP
55296-55551
TCP
80, 8080, 443, 55296-55551

FFXI (game)
TCP 25, 80, 110, 443 or 50000 - 65535
UDP 53, 50000 - 65535

Webbrowsing
TCP/UDP 80, 443

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.

landis port 80 is an assigned port for http, you cannot choose it for the listening port in vuze. You must choose an unassigned port above 1024 see here Select port for Vuze - VuzeWiki

landis port 80 is an assigned port for http, you cannot choose it for the listening port in vuze. You must choose an unassigned port above 1024 see here Select port for Vuze - VuzeWiki

Did you happen to see this? (below)

HTTP Seeding - VuzeWiki

Did you happen to see this? (below)

HTTP Seeding - VuzeWiki

The info that is linked on that page says it is for a http server, are you running a http server? I think the implementation is to download from a http server, which would be different than the default scenario we are trying to configure in this case.

Let me ask, have you had Vuze running previously with this config with or without the UTM in place?

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

Once you have the Vuze problem solved, search the Firewall logs to see which rules aren't being used.  Search for each rule with fwrule="#", replacing # with each number.

Cheers - Bob

Hi, lots of people run their torrent clients with port 80 as the listening port.

As long as you don't have a web server running on 80, and your ISP doesn't block port 80 inbound (many ISPs do block), then there shouldn't be a problem.

Barry