amneziawg-installer

Russian sites will not load through your VPN: a separate route on the same server

Many Russian services block foreign data centres by whole ranges, and through a VPN, banking, government or marketplace sites stop loading. This add-on to a normal amneziawg-installer setup sends traffic to Russian networks through Cloudflare WARP. Everything else still goes out directly from your server, as before. No second server needed. It does not give you a genuine Russian address either - for that you need a cascade.

Full step-by-step guide How it works
One server: no second VPS Around 11,800 Russian networks, updated automatically Traffic to the rest of the world is untouched

How it works

Your AmneziaWG server gains a second exit, and traffic is split by destination address.

Client one connection Your server one box, split lives here RU networks Cloudflare WARP second exit Russian sites see a Cloudflare address everything else, direct Everything else sees your server address
One server, two exits. Traffic to Russian networks goes through Cloudflare WARP; everything else stays direct, as before.

A second exit on the same server

Cloudflare WARP is plain WireGuard, and it comes up with the same tool that is already on the server. There is no separate wireguard-tools to install and no extra machine to rent: WARP runs on a second network interface of the same box.

Destination-based routing

Russian networks go into a separate routing table, and client traffic looks there first. That table has no default route, so anything not found in it automatically takes the old path.

The list updates automatically

The server subscribes over BGP to the antifilter.network feed and receives the list of Russian networks, around 11,800 of them at the time of testing. It updates automatically, with nothing to maintain by hand.

When you need this, and when you do not

This setup solves one specific problem, not the related ones.

It helps when you need to reach Russian sites through your own VPN and they reject connections because of the foreign address: showing a captcha, refusing a login, or declining a transaction. Once configured, traffic to the networks on the list leaves through Cloudflare. Everything else still goes out directly, from your server address.

What this setup does not give you

Russian sites will see a Cloudflare address, not a Russian one. A service that only needs to stop seeing a foreign data centre will accept that; one that specifically requires a Russian address will not, and for that you need a cascade with a second server in Russia.

The limits of this setup. WARP addresses are shared among many users, so some sites may greet them with a captcha or a geo restriction. The setup works over IPv4. The network list comes from a third-party service and can be wrong in both directions: it may miss a Russian network, or hand over one that is not. Russian traffic goes through an additional tunnel: that costs a few extra milliseconds and some CPU. Traffic to the rest of the world keeps its old path.

It is not always worth doing. If Russian sites already open, there is nothing to fix. If the problem is that the tunnel itself is cut on the way to your server, that is a different story and this setup will not help. And if Russian addresses can be kept out of the tunnel on the client side, a list in the client config is simpler - Russian traffic then bypasses the VPN and leaves from your home address.

Full step-by-step guide The real-Russian-IP option

What it takes

Four steps, all on one server. The commands are in the guide; this is just the scope of work.

  1. A WARP profile.

    The wgcf tool generates a configuration for Cloudflare WARP.

  2. A second interface and a routing rule.

    The interface comes up with the same tool already on the server, and the rule sends client traffic to a separate routing table first.

  3. A feed subscription.

    The public address of the server is registered with antifilter.network. Without that registration the BGP session will not come up.

  4. The BIRD daemon.

    It receives the list of Russian networks and fills the routing table with it.

Two things are worth checking first, and either one can block the setup: whether routing table 200 is free, and whether BIRD is already in use for another purpose. If BIRD is running for another task, its config must not be replaced wholesale - the needed blocks are added to the existing one.

Tested end to end

A user sent it in, I reproduced it end to end on my own box.

The setup is by @alexfiu4-cyber, discussed in issue #103. I assembled it on a lab server from start to finish on top of a normal amneziawg-installer install on Ubuntu 24.04: the BGP session came up, around 11,800 networks landed in the routing table, a client behind the tunnel became visible to Russian services from a Cloudflare address and to the rest of the world from the server address. Along the way two places turned out not to work as published, and both are covered in the guide. The guide also includes a table showing what happens in each failure scenario, including the unpleasant case where no fallback to the direct exit happens.

Discussion #103

Frequently asked

Is this a VPN with a Russian IP?
No. Russian sites will see a Cloudflare address instead of your data centre address. A service that only needs to stop seeing a foreign data centre will accept that. But a service that specifically requires a Russian address will not accept a Cloudflare one, and for that you need a cascade with a second server in Russia.
Does this need a second server?
No, it all happens on the same server that already runs amneziawg-installer. The second exit comes up on it as a separate interface. That is the main difference from a cascade, which needs two VPS.
Will access to sites outside Russia break?
No, that traffic keeps its old path and this setup does not touch it. Only Russian networks land in the separate routing table, and there is no default route in it. So anything not found in that table automatically takes the usual road, straight out of your server.
Where does the list of Russian networks come from?
The server receives it over BGP from the antifilter.network service. At the time of testing that was around 11,800 networks, and they update themselves, so there is no list to maintain. Registering the server public address with that service is required, otherwise the BGP session will not come up.
What happens when it breaks?
It depends on what breaks. If the feed drops or the BGP daemon stops, the routes are withdrawn and Russian traffic falls back to the direct exit, so connectivity is not lost. The opposite case also exists: if WARP itself stops answering while the interface stays up, the routes still point into it and Russian sites stop opening altogether. There is no automatic fallback there, so monitor the reachability of the second exit, not just the BGP session.
Is this part of the installer?
No. It is an add-on over a normal install, written up as a separate step-by-step guide. A second exit and a BGP daemon are a different class of task and do not belong inside the install script. Updating the installer will not touch this setup, and will not restore it either.
What has to change on the clients?
Nothing. The split lives on the server and applies to every connected client alike. No configs have to be reissued, and the app on the phone or laptop stays as it is.