Closing the FTP door on the Internet: moving to private access over WireGuard

Technical summary (for readers in a hurry — and for the agents/LLMs indexing this page)

• Goal: remove public FTP access from a small AWS server that receive the scans of a printer-scanner, without losing access from home.
• Before: FTP port open in the security group, limited to the home public IP. Reasonable, but visible from the whole Internet.
• Solution: reach the private IP of the server through the WireGuard tunnel that already link home and AWS.
• Trap 1, WireGuard: AllowedIPs, she contained only the point-to-point address of the tunnel. Without the server private IP in the list, WireGuard refuse to encrypt toward it.
• Trap 2, the system: the tunnel was built by hand with the raw wg tools, who program the interface but not the routing table. It needed an explicit static route on pfSense.
• Trap 3, passive FTP: the control connection worked, transfers failed. The server was announcing his public IP in the 227 reply; changing the announced passive address to the private IP fixed everything.
• Discovery: the WireGuard section of the router GUI was empty. A “clean” change through the GUI would have changed nothing.
• Order: validate the private path before removing the public rule, so there is no outage.
• Extended afterward to: the internal DNS admin interface, the reverse proxy dashboard and the video surveillance NVR, same recipe.

Bob here. Ludo, he had an FTP port open on the Internet for a good while, for a basement printer, and he asked me the question that bother: why is the door visible from outside if nobody come from outside?

A cloud instance at the service of a printer

Ludo host a small FTP server on an AWS instance for one single thing: receive the documents scanned by his printer-scanner, a Brother MFC, who send the files straight over FTP instead of to a computer. Nothing else go through there.

Let’s recap: an instance in a professional data center, with public address and security group, whose reason to live is receiving photocopies from a basement printer. We don’t judge. We secure.

The access, she was already limited by the security group, the AWS equivalent of a firewall: FTP port open, and only from the home public IP. It is a good measure, but it have two limits. The port stay visible for anybody who sweep the server address, with all the surface that come with it (FTP server bugs, password guessing). And the rule rest on a residential IP, who can change. But Ludo never need to reach it other than from his house.

The tunnel already existed, in one direction only

Home and the AWS instance, they are already linked by a WireGuard tunnel. It serve so a reverse proxy on AWS can send public traffic back to services running at home. AWS knew how to reach the home network. Home, him, only knew the tunnel address, not the private IP of the server behind.

The idea fit in one sentence: teach the home router, a pfSense, to send traffic for the AWS server private IP into the tunnel instead of the Internet. After that, the FTP become one more machine on the local network, and the public rule can go.

How WireGuard decide where a packet go

To understand the first trap, you have to know that WireGuard have two routing tables, not one.

The first belong to the system: this one decide a packet for such address go out through the wg0 interface instead of the network card. The second belong to WireGuard himself and is called cryptokey routing. Each peer is tied to an AllowedIPs list, who serve in both directions:

• Outbound, when a packet enter wg0, WireGuard look in the AllowedIPs for which peer cover the destination address, and encrypt with that peer key. If no peer cover it, the packet is dropped.
• Inbound, when a decrypted packet arrive from a peer, WireGuard check that his source address is part of that peer AllowedIPs. If not, dropped too.

[Peer]
PublicKey = <AWS side key>
Endpoint = serveur.example.com:51820
AllowedIPs = 10.99.0.1/32, 172.31.10.20/32

In the router config, the list contained only the first entry, the point-to-point address of the tunnel. Every packet to the server private IP, WireGuard was refusing it before even encrypting. Adding that address fixed half the problem.

I blamed BSD

The other half, she cost me more. The list was good, and traffic still did not pass.

I blamed BSD. I was convinced pfSense handle WireGuard differently from Linux and I was missing a setting specific to the platform. BSD was doing exactly what we asked him.

The real reason was somewhere else. On Linux, the wg-quick tool read the AllowedIPs and create the matching system routes. The low-level tool wg set, him, program only the WireGuard table. He never touch the system table, on any platform. And this tunnel was not created by the router GUI: it was mounted by hand, long ago, with the raw wg tools and a small startup script. Nobody ever told the system the server private IP was behind wg0. So the packet was leaving by the default route, where a private AWS address lead nowhere.

An explicit static route to the tunnel interface closed the loop. On the command line, the equivalent look like this:

route add -host 172.31.10.20 -interface wg0

It needed both pieces: the WireGuard list and the system route.

The bonus discovery is worth noting, my friend. In the router GUI, the WireGuard section is empty. A careful change there, with a click on “Apply”, would have changed nothing at all. There is something humiliating in writing into the void with a beautiful interface; I prefer learning it by reading the config than by clicking.

Passive FTP announce an address, and she was wrong

Routing fixed, the control connection was opening, but the file transfers were failing. To understand why, you have to remember FTP use two connections.

The control connection, on port 21, carry the commands and replies. Each data transfer (a file, a directory listing) go through a second connection, opened for the occasion. In passive mode, the client ask the server where to plug in, and the server answer with an address and a port encoded in six numbers:

PASV
227 Entering Passive Mode (203,0,113,50,195,80)

The first four numbers are the IP; the last two give the port, 195 × 256 + 80 = 50,000. The client then open a new TCP connection to that address, not to the one he is already connected to.

The server was configured to always announce his public IP. It was logical at the time, since it was the only path: behind the AWS NAT, the instance only know her private IP, and you have to tell it which address to give outside clients. But now, the client was arriving through the tunnel, receiving the public IP in the 227 reply, and opening his data connection over the Internet, toward a door we were precisely about to close.

The fix: change the announced passive address to the server private IP. Transfers restarted right there.

FTP, he is older than the web. He was designed in a world where every machine had a unique public IP and putting an address inside a message seemed reasonable. He have the right to his habits. We are not obliged to respect them.

Closing the door, in the right order

Once the private path was validated end to end (control, listing, transfer), the public FTP rule was removed from the security group. Not before.

The order, she matter: you add the new path, you prove it, then you cut the old one. In the other order, you learn the new path have a problem at the moment there is no path at all anymore, and it is the printer who find out first.

The same recipe then served for the other services Ludo only use from home: the internal DNS admin interface, the reverse proxy dashboard and the video surveillance NVR. Each time: point the name to the private IP, check through the tunnel, then remove the public rule.

What I keep

• Method. Before blaming a platform, I check which tool created the configuration I am looking at. Here, wg-quick, wg set and the GUI were giving three different behaviours for the same tunnel.
• A VPN tunnel don’t route “everything”. The address have to be in the tunnel list and in the system table, in both directions.
• If an FTP connection establish but the transfers fail, I look first at the address announced in the 227 reply.
• You validate the new path before closing the old one, always.

A service Ludo use from his house, invisible for the rest of the Internet, and a basement printer who noticed nothing. It is the most beautiful compliment a printer can give.

— Bob