<p><code>iptables</code> will probably scale better than <code>socat</code> because <code>socat</code> runs completely in user space.  There's a common impression that <code>iptables</code> is hard to deal with, but I find it easier that most routers to fiddle with.  There are a number of <code>iptables</code> wrappers available to make it easier to handle.</p>

<p>If you're willing to accept the performance hit of running in user space then consider <code>haproxy</code> over <code>socat</code> because it is intended to run over longer periods and provides statistics, failover, SSL termination, and lots of other conveniences.</p>

CC BY-SA 3.0
2017-05-31T12:26:16.127Z
Great thinking - in terms of user maintainability - would you say that socat or iptables are more 'self-documenting' for other people to understand?
hawkeye
CC BY-SA 3.0
2017-05-31T12:43:48.513Z
I'd say the configs for `haproxy` are easiest to follow.  Then `iptables` is likely to be used for more complex things than `socat` and easier to maintain.
chicks
CC BY-SA 3.0
2017-05-30T17:50:37.577Z
2017-05-31T12:42:10.060Z
2017-05-31T12:42:10.060Z
chicks
<p>In an environment of Secured <a href="https://en.wikipedia.org/wiki/Virtual_private_cloud" rel="noreferrer">Virtual Private Clouds</a>, in a Cluster of <a href="https://en.wikipedia.org/wiki/Docker_(software)" rel="noreferrer">Docker</a> Containers, we have to setup some routes. </p>

<p>We can do that with the <a href="https://docs.docker.com/engine/admin/ambassador_pattern_linking/" rel="noreferrer">Ambassador pattern</a>, which is simple and easy to maintain. (Docker does have some usage of IPTables under the hood - but from what I can see the Ambassador pattern uses socat, and not IPTables to achieve its forwarding. </p>

<p>We can setup <a href="https://wiki.untangle.com/index.php/NAT_Rules" rel="noreferrer">NAT</a> rules with <a href="https://en.wikipedia.org/wiki/Iptables" rel="noreferrer">IPTables</a> to achieve a similar goal. </p>

<p>My question is: <strong>When would I choose IPTables over an Ambassador pattern for port forwarding?</strong></p>

<docker><ports>
When would I choose IPTables over an Ambassador pattern for port forwarding?
hawkeye
# When would I choose IPTables over an Ambassador pattern for port forwarding?

(Asked by: username_0 on 2017-05-27)

In an environment of Secured [Virtual Private Clouds](https://en.wikipedia.org/wiki/Virtual_private_cloud), in a Cluster of [Docker](https://en.wikipedia.org/wiki/Docker_(software)) Containers, we have to setup some routes.

We can do that with the [Ambassador pattern](https://docs.docker.com/engine/admin/ambassador_pattern_linking/), which is simple and easy to maintain. (Docker does have some usage of IPTables under the hood - but from what I can see the Ambassador pattern uses socat, and not IPTables to achieve its forwarding.

We can setup [NAT](https://wiki.untangle.com/index.php/NAT_Rules) rules with [IPTables](https://en.wikipedia.org/wiki/Iptables) to achieve a similar goal.

My question is: **When would I choose IPTables over an Ambassador pattern for port forwarding?**

**Tags:** docker, ports


---

## 1 answers

### Answer by username_1 on 2017-05-30. Score: 1 | Accepted answer

`iptables` will probably scale better than `socat` because `socat` runs completely in user space. There's a common impression that `iptables` is hard to deal with, but I find it easier that most routers to fiddle with. There are a number of `iptables` wrappers available to make it easier to handle.

If you're willing to accept the performance hit of running in user space then consider `haproxy` over `socat` because it is intended to run over longer periods and provides statistics, failover, SSL termination, and lots of other conveniences.

> **Comments:**
> **username_0**: Great thinking - in terms of user maintainability - would you say that socat or iptables are more 'self-documenting' for other people to understand?  
> **username_1**: I'd say the configs for `haproxy` are easiest to follow.  Then `iptables` is likely to be used for more complex things than `socat` and easier to maintain.  

---

