Mirroring all traffic from one port to another for monitoring in Linux

You've setup basically the worst case scenario and are apparently determined to stick with it.

Putting the server publicly accessible from the Internet is just asking for trouble as you have found out. The correct solution is to setup a VPN and use that. I'm curious why you don't want to. It adds a single step to the process of connecting to the server and provides a major level of security to the environment as people can't access your SQL Server directly.

While it's much easier to simply access your servers from the public Internet it's much more dangerous just to save yourself the step of VPNing in.

And who's to say that another bug like that one that let SQL Slammer destroy SQL Servers all over the net won't happen again with your SQL Server at risk.

In answer to your question, no there's no way to tell the SQL Server to ignore these connection requests as they are legitimate connection requests.

Or you could use targetless iptables, which is quite legal and harmless:

iptables -A INPUT -p tcp --dport 3000
iptables -A INPUT -p tcp --dport 3001
...
iptables -A INPUT -p tcp --dport 3050

and

iptables -A OUTPUT -p tcp --sport 3000
iptables -A OUTPUT -p tcp --sport 3001
...
iptables -A OUTPUT -p tcp --sport 3050

Since none of these rules has a target, none of them will change the traffic flow. But each of them will increment its packet and byte counts for each matching packet, so iptables -L -n -v should return something like

15733  933K           tcp  --  * *      0.0.0.0/0      0.0.0.0/0     tcp dpt:3000
5733   133K           tcp  --  * *      0.0.0.0/0      0.0.0.0/0     tcp dpt:3001
...

Note this assumes you aren't using any firewalling right now; if you are, these rules will need to go in the right place in the INPUT and OUTPUT chains, ie, first.

Given the number of ports you're monitoring, you might want to delegate this to a user-defined chain to keep your iptables output sane; but that's an exercise for you!