Assuming you are speaking about Linux, iptables has a mangle table that can do all sorts of crazy things to outgoing TCP traffic. iptables NAT features might help as well, because it really sounds like you want to do "port address translation" or "manual NAT."
netstat
There's a process there, your userid just isn't privy to seeing what it is. This is a layer of protection provided by lsof that's keeping you from seeing this. Simply re-run the command but prefix it using the sudo command instead.
$ sudo netstat -antlp | grep 45136
There's even a warning about this in the output of lsof at the top.
(Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.)
Example
$ netstat -antlp | grep 0:111
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN -
$ sudo netstat -antlp | grep 0:111
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1248/rpcbind
ss
If you're not having any luck with netstat perhaps ss will do. You'll still need to use sudo, and the output can be a little bit more cryptic.
Example
$ ss -apn|grep :111
LISTEN 0 128 :::111 :::*
LISTEN 0 128 *:111 *:*
$ sudo ss -apn|grep :111
LISTEN 0 128 :::111 :::* users:(("rpcbind",1248,11))
LISTEN 0 128 *:111 *:* users:(("rpcbind",1248,8))
Process ID still not there?
There are instances where there simply isn't a PID associated to the TCP port in use. You can read about NFS, in @derobert's answer, which is one of them. There are others. I have instances where I'm using ssh tunnels to connect back to services such as IMAP. These are showing up without a process ID too.
In any case you can use a more verbose form of netstat which might shed additional light on what process is ultimately using a TCP port.
$ netstat --program --numeric-hosts --numeric-ports --extend
Example
$ netstat --program --numeric-hosts --numeric-ports --extend |grep -- '-' | head -10
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 192.168.1.103:936 192.168.1.3:60526 ESTABLISHED root 160024310 -
tcp 0 0 192.168.1.1:2049 192.168.1.3:841 ESTABLISHED sam 159941218 -
tcp 0 0 127.0.0.1:143 127.0.0.1:57443 ESTABLISHED dovecot 152567794 13093/imap-login
tcp 0 0 192.168.1.103:739 192.168.1.3:2049 ESTABLISHED root 160023970 -
tcp 0 0 192.168.1.103:34013 192.168.1.3:111 TIME_WAIT root 0 -
tcp 0 0 127.0.0.1:46110 127.0.0.1:783 TIME_WAIT root 0 -
tcp 0 0 192.168.1.102:54891 107.14.166.17:110 TIME_WAIT root 0 -
tcp 0 0 127.0.0.1:25 127.0.0.1:36565 TIME_WAIT root 0 -
tcp 0 0 192.168.1.1:2049 192.168.1.6:798 ESTABLISHED tammy 152555007 -
If you notice the output includes INODES so we could back track into the process using this info.
$ find -inum 152555007
Which will show you a file which might lead you to a process.
References
Best Answer
One way is to say
lsof -i:57010 -sTCP:ESTABLISHED. This walks the kernel's open file handle table looking for processes with an established TCP connection using that port. (Network sockets are file handles on *ix type systems.) You'd use-sTCP:LISTENon the server side to filter out only the listener socket instead.Because of the way
lsofworks, it can only see processes your user owns unless you run it as root. It's also fairly inefficient, since a typical *ix system has a lot of file handles open at any given time. Thenetstatmethod given in another answer is faster and usually has lower access requirements.The
lsofmethod has one great advantage, however: not all *ix type OSes have anetstatflag for including the process name in the output, whereaslsofhas been ported to every *ix type OS you're likely to use. OS X'snetstatis this way, for example. It has a-poption, but it does something different fromnetstat -pon Linux.For an uncommon port number like the one in your question, you can typically get away without adding
lsof's-sflag, because a given machine is unlikely to have programs both connecting to the port and listening on it. It can be helpful to add it with port numbers like HTTP's 80, where it is likely you'll have multiple programs using that port at once.It's fortunate that the
-sflag is optional in many situations, because that usage only works withlsofversion 4.81 and newer. In older versions,-smeant something else entirely! That's a 2008 vintage change, but it can still bite unexpectedly. RHEL 5 ships withlsof4.78, for example.