Extremely long routing tables

eliotcougar

I'm using OpenVPN for circumventing Russian Internet firewall right now using my own server abroad.
In order to do that I've configured some scripts that fetch the list of all blacklisted IPs, merge them into networks where possible, and generate the file with all the route commands for OpenVPN on the server side.
There are some problems with that.
On Windows adding all the 26812 routes (and the number is growing every week) takes very long time, especially on slow computers. It wouldn't be a big problem if OpenVPN started working before adding routes, but it doesn't forward packets until all the routes are set up by Windows. And since OpenVPN does not signal an established connection, it sometimes disconnect it and tries to reconnect before all the routes are added, because some timeout has passed. When it does so, it deletes all the added routes one by one, which is as slow as adding them, and this disconnect-reconnect cycle may repeat endlessly. Right now I have to set connection timeout settings to incredible values (6 hours), and as a result detection of a genuine connection failure that would require a reconnect fails.
If OpenVPN didn't add the specific route yet I see "Website is blacklisted" message from my ISP. If OpenVPN has already added the specific route, but not all routes are added yet, I just see "connection timeout" because OpenVPN doesn't forward packets yet. And only after all the routes are added, it starts working.

Is it possible to make OpenVPN signal connection active before all the routes are added, and make it forward packets while those routes are being added one by one in background? This way I may even be able to prioritize routes in the list, making important/popular ones be added sooner after connection.

ValdikSS

Hi. I think you're using antizapret scripts. Several months ago it worked fine, you need to increase keepalive value to 10 mins or more on both server and client:

keepalive 35 660

Anyway, current antizapret's VPN is pushing only one huge "fake" network (/22) with it's remapping DNS server. If DNS request is done to the blocked domain, remapping DNS server adds iptables NAT translation from fake address to a real A record and returns fake address to the client. This server is not published yet, but if you need it, I can polish and upload it.

eliotcougar

ValdikSS wroteHi. I think you're using antizapret scripts.

No, I'm using my own script. It is not automated. I run it on my machine and then transfer the new routes list to my VPS.
Right now I use keepalive 300 21600 because one of my slower machines takes 1.5–2.0 hours to add all routes depending on the CPU load.

Using fake DNS method would mean I'll have to do all DNS requests through this VPN. Maybe I'll do it when my ISP start spoofing Google's DNS...

TinCanTech

I think an easier way to achieve your goal is to download a file from the server with all the necessary route information and then process that. It must be done manually or by some other method *outside* of openvpn.

eliotcougar

I have found the source of the connection problem finally when the route list grew so big the connection took 2+ hours... It turns out that if the TLS renegotiation happens during the process of adding routes twice, the whole connection becomes broken... Ability to communicate with VPN server during the addition of routes would fix this, but for now adding
reneg-sec 86400
tran-window 86400
to both server conf and client conf, is the only thing that makes it possible to establish connection at all... Otherwise it fails to renegotiate new TLS key and loses the stale TLS key too...

Why exactly OpenVPN client cannot route traffic until the whole 40000 routes are added one by one to the windows routing table?..

eliotcougar

I am sad... This is sad... I don't want to do this anymore... 🙁
Route addition gets very slow very quickly, depending on the CPU... I now have to route the entire /24 subnet if only just 2-3 IPs from it are blocked by the ISP... Otherwise, the list of routes gets unwieldy for the OS, and takes hours to connect...
Why is there no way in the OS to update the entire routing table in one go...

TinCanTech

Find another approach ...