Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

How can I route all outgoing packets from all applications from their respective source ports to port x so they all look as if they come from port x. Is it possible ?

I do not know much about iptables but I tried these rules and they are not correct syntax:

iptables --table nat --append POSTROUTING --protocol TCP --source-port 1:65534 --jump REDIRECT --to-port 9999
# copy and paste exact rule but for UDP :
iptables --table nat --append POSTROUTING --protocol UDP --source-port 1:65534 --jump REDIRECT --to-port 9999
share|improve this question
WHY do you want to do this? – voretaq7 Jun 22 '11 at 18:25
Why would you want to do this? It will likely break many things. – Flimzy Jun 22 '11 at 18:26
This breaks down when you have multiple outbound connections... – Kyle Smith Jun 22 '11 at 18:39

The REDIRECT target is not what you want. REDIRECT is for when you want to intercept a connection that would normally route through your box and instead redirect it to a local port. This is often used when implementing some sort of transparent proxy solution. In this model you would have a service listening on the target port (9999 in your example) that would respond to the traffic.

The SNAT (source NAT) and MASQUERADE targets get closer to what you want, but I'm not sure that any of this is going to work with locally generated traffic (that is, with connections originating on the same system on which you are implementing this iptables rules)...

...and as Kyle has pointed out in the comments, even if you are able to implement a "successful" solution you're going to break everything if you are ever running more than on application at a time.

If you can provide some more details on exactly what problem you're trying to solve we may be able to suggest a better solution.

share|improve this answer

I do not know if this is possible. I suspect even if it is you shouldn't use it, as by itself it breaks the assumptions that the TCP/IP model makes about the Application layer (IP+port = socket = 1 application daemon). It's the same reason you can't forward ports from one single port on a firewall to multiple ports on multiple hosts with NAT alone (unless you're load balancing the same application, but you'd need something more complex than NAT and iptables to accomplish that, I think).

Applications generally bind to a given port, and this will block attempts by other applications to bind to the same port. This binding is how the operating system's netcode knows which application gets the packet. This is why you can't run Apache and lighttpd on port 80 at the same time. Think about the packet. All the transport layer has to work with is IP address, port number of the source and destination (plus the session ID, but no if session has been established yet it, too, is useless). Which daemon gets it of both are bound to one port?

You can "fake" this type of thing if you have a super-server daemon like inetd or xinetd, or remote command relays like RPC and WMI, but each client application has to know it needs to specify the destination at the application layer or the requests must be protocol-specific.

share|improve this answer

Depending on what you want to do exactly, I would look into how to set up "Source NAT". A good reference seems to be on the netfilter HOWTO section 6.1. Here, the netfilter framework keeps track of the change and also rewrites/reroutes responding answers to the correct sending port.


polaris:~# iptables -t nat -A POSTROUTING -d qew -p tcp --destination-port 1444 -j SNAT --to :2347
polaris:~# telnet qew 1444
Connected to qew.
Escape character is '^]'.
hello world

and on the other side:

qew:~# nc -l -p 1444
hello world

In another shell showing that the source port of the packets from polaris to qew were actually changed.

qew:~# netstat -n |grep 1444
tcp        0      0         ESTABLISHED

If you do not want to have connections magically stay alive, you can also try to modify the packets directly. I can't find a target that does so for ports, but there is an extension that allows changing the TTL field, so I might just not have looked carefully enough.

Last resort would be to use the QUEUE target to route your packets to user-land, modify them, update all the checksums, and then give them back to the kernel.

share|improve this answer
Of course, as pointed out by the other answers, this is usually not a good idea to do so. My answer shows ways on how to do so if you have good reasons. – user85382 Jun 22 '11 at 19:56

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.