Before Replacing IPsec With Shadowsocks, List the Missing Jobs

Three services, one tunnel: a web app, a database, and a file share. Someone suggests swapping IPsec for Shadowsocks because it is simpler to run. The encryption debate that follows misses the point, because the tunnel is doing several jobs at once and only one of them is about ciphers. Write those jobs down before comparing products. The list is short, and any single item can invalidate the swap.

Start with how traffic gets captured

The protocol has two halves. A local component accepts a connection, encrypts a stream that begins with the destination address, and sends it to a remote component. The remote half opens a connection to that destination and relays the bytes. UDP follows the same shape with datagrams. This is forwarding for the flows it captures, and it says nothing about the flows it does not. An application that speaks a proxy explicitly is easy; everything else needs an adapter or routing rules to be captured at all.

Document the capture method per application before comparing anything else. Uncaptured traffic leaves by the ordinary path, and nobody notices until a service behaves differently off-site.

Name every destination and protocol

The remote half must be able to reach each internal service. A working encrypted session to that host does not add a route from it to the database, and it does not make internal names resolve on the client. List addresses, ports, and protocols instead of writing down that the LAN is included.

Add the cases that break tidy designs: internal DNS, applications that ignore proxy settings, and any flow that must be initiated from the server toward the client. Each needs an explicit arrangement, not an assumption.

Encryption is not authorization

The documented AEAD methods in Shadowsocks provide authenticated encryption, so dismissing the whole family as insecure is wrong. Letting that fact answer the access question is equally wrong. Someone has to decide who reaches which service, how access is removed when a person leaves, where secrets are stored, and which component enforces the boundary. A single shared secret gives every holder the same reach, and offboarding one person becomes a rotation for everyone.

Hold the current IPsec setup to the same standard. Its label does not prove its rules are right, and comparing a polished version of one design with a vague version of the other decides nothing.

List the controls that exist today on both sides, then judge which gaps you can live with.

Count the operational work

Every replacement needs an owner for client packages, server updates, credential rotation, and failure handling. Note what each application does when the tunnel is unavailable: fail, retry over the local path, or wait. That behavior comes from the deployment, not from the protocol name.

For one web application, a narrow proxy can be enough. For whole-network access with per-person permissions, the extra pieces usually cost more than the tunnel they replaced.

The decision is not which product sounds safer. It is which design finishes the listed jobs with controls the team will actually maintain.