I ran a scan with
nmap -n -vv -A x.x.x.x --min-parallelism=50 --max-parallelism=150 -PN -T2 -oA x.x.x.x

With the following result:
Host is up (0.032s latency).
Scanned at 2012-10-25 16:06:38 AST for 856s
PORT      STATE SERVICE    VERSION
1/tcp     open  tcpwrapped
3/tcp     open  tcpwrapped
4/tcp     open  tcpwrapped
.
.
19/tcp    open  tcpwrapped
20/tcp    open  tcpwrapped
21/tcp    open  tcpwrapped
22/tcp    open  tcpwrapped
23/tcp    open  tcpwrapped
.
.
64623/tcp open  tcpwrapped
64680/tcp open  tcpwrapped
65000/tcp open  tcpwrapped
65129/tcp open  tcpwrapped
65389/tcp open  tcpwrapped

Scan methodology was
I'm sure that this is a firewall's or load balancer's game.
I tried many ways, such as change source port, source IP, fragmentation, etc..

Do you have any idea/suggestion to bypass this case?
On another hand, do you know how to do that in a firewall policy (on any firewall)?


"tcpwrapped" refers to tcpwrapper, a host-based network access control program on Unix and Linux. When Nmap labels something tcpwrapped, it means that the behavior of the port is consistent with one that is protected by tcpwrapper. Specifically, it means that a full TCP handshake was completed, but the remote host closed the connection without receiving any data.

It is important to note that tcpwrapper protects programs, not ports. This means that a valid (not false-positive) tcpwrapped response indicates a real network service is available, but you are not on the list of hosts allowed to talk with it. When such a large number of ports are shown as tcpwrapped, it is unlikely that they represent real services, so the behavior probably means something else.

What you are probably seeing is a network security device like a firewall or IPS. Many of these are configured to respond to TCP portscans, even for IP addresses which are not assigned to them. This behavior can slow down a port scan and cloud the results with false positives.

EDIT: Since this post was flagged as plagiarism and deleted, I would like to point out that the assumed source (this page on SecWiki.org) was also written by me. This Security.StackExchange answer (October 31, 2013) predates that page (November 12, 2013) by nearly two weeks. 
