<joke>Unplug it</joke>
Bittorrent clients can (and do) use random ports. Blocking the common ports will only encourage users to move to different ports. Also, the inter-client traffic has supported encryption for some years now -- originally as a means to limit ISP interference -- making the actual p-t-p traffic unrecognizable.
Looking for "info_hash" in the client-tracker communication, while somewhat effective, is also easily defeated. (tor, ssl, vpn, etc.) It also does nothing to stop tracker-less swarms (DHT), peer-exchange (PEX), UDP tracker protocol...
If you've managed to kill 50%, count yourself lucky. This is a game of whack-a-mole you cannot win.
I'm not entirely sure if I understand your question, but I believe you want to take a look at the show xlate
command.
For example:
myfirewall1/act/pri# show xlate
732 in use, 3000 most used
Flags: D - DNS, e - extended, I - identity, i - dynamic, r - portmap,
s - static, T - twice, N - net-to-net
NAT from inside:172.16.8.0/24, 172.16.5.0/24, 172.17.60.0/24,
172.17.10.0/24, 172.17.50.0/24, 172.16.4.0/24,
172.16.6.0/24, 172.16.7.0/24, 172.17.40.0/24,
172.17.30.0/24 to outside:172.16.8.0/24, 172.16.5.0/24,
172.17.60.0/24, 172.17.10.0/24, 172.17.50.0/24,
172.16.4.0/24, 172.16.6.0/24, 172.16.7.0/24,
172.17.40.0/24, 172.17.30.0/24
flags sIT idle 0:00:00 timeout 0:00:00
[output cut...]
TCP PAT from inside:172.16.8.54/53008 to outside:177.36.241.90/53008 flags ri idle 0:32:23 timeout 0:00:30
TCP PAT from inside:172.16.4.52/20592 to outside:177.36.241.90/20592 flags ri idle 0:14:26 timeout 0:00:30
TCP PAT from inside:172.16.6.61/49776 to outside:177.36.241.90/49776 flags ri idle 0:00:16 timeout 0:00:30
TCP PAT from inside:172.16.6.61/63274 to outside:177.36.241.90/63274 flags ri idle 0:53:37 timeout 0:00:30
...
...
You can pipe the output to include
to filter on the IP addresses in question:
myfirewall1/act/pri# show xlate | include 172.16.5.56
TCP PAT from inside:172.16.5.56/59970 to outside:177.36.241.72/59970 flags ri idle 0:00:05 timeout 0:00:30
TCP PAT from inside:172.16.5.56/59958 to outside:177.36.241.72/59958 flags ri idle 0:00:29 timeout 0:00:30
TCP PAT from inside:172.16.5.56/59914 to outside:177.36.241.72/59914 flags ri idle 0:00:54 timeout 0:00:30
Or you can narrow the scope with the global, gport, interface, local, lport options.
ncapfw1/act/pri# show xlate ?
count Show translation count
global Enter this keyword to specify global ip range
gport Enter this keyword to specify global port(s)
interface Enter this keyword to specify an interface
local Enter this keyword to specify local ip range
lport Enter this keyword to specify local port(s)
type Enter this keyword to specify xlate type
| Output modifiers
<cr>
myfirewall1/act/pri#
myfirewall1/act/pri#
myfirewall1/act/pri# show xlate global 177.36.241.72
863 in use, 3000 most used
Flags: D - DNS, e - extended, I - identity, i - dynamic, r - portmap,
s - static, T - twice, N - net-to-net
TCP PAT from inside:172.16.5.61/38464 to outside:177.36.241.72/38464 flags ri idle 0:29:30 timeout 0:00:30
TCP PAT from inside:172.16.5.61/36269 to outside:177.36.241.72/36269 flags ri idle 0:29:30 timeout 0:00:30
TCP PAT from inside:172.16.5.61/57396 to outside:177.36.241.72/57396 flags ri idle 0:29:33 timeout 0:00:30
TCP PAT from inside:172.16.5.61/42706 to outside:177.36.241.72/42706 flags ri idle 0:55:22 timeout 0:00:30
...
...
Hope this helps!
Best Answer
The easiest way to figure out why your ASA drops traffic:
packet-tracer
capture [NAME] asp-drop
Using
packet-tracer
(only on routed ASA firewalls):Routed firewalls give us the most information when we need to figure out why something was dropped; it's best to use
packet-tracer
to figure out why the routed firewall dropped something (although it won't catch every possible case).I'm assuming 172.16.1.5's source port is 1024 for the purposes of getting a diagnosis... The syntax is
packet-tracer input INSIDE tcp [SRC_HOST] [SRC_PORT] [DST_HOST] [DST_PORT]
Using
capture [NAME] asp-drop
(routed or transparent ASA firewalls):Transparent firewalls are trickier to diagnose, but you can still get some useful information with the
capture ... asp-drop
command. The ASP is the ASA's "Accelerated Security Path"; this is where many drops happen. I have seen some dropped traffic that doesn't show inasp-drop
, but usually that's because of an overwhelmed backplane in the ASA.There are four steps...
capture [CAPTURE_NAME] type asp-drop all buffer [BUFFER_SIZE] match tcp host [SRC_HOST] host [DST_HOST] eq [DST_PORT]
show capture [NAME] trace
to understand why the traffic was denied.no capture [CAPTURE_NAME]
This is an example which shows traffic to 4.2.2.2 on tcp/9000 is denied by a configured firewall rule.
When you finish, be sure to unconfigure the capture with
no capture DENY