openvpn spuriouslyk records each and every used IPv6 of the range

[sthibault]

Hello,

We are using OpenVPN to route whole /64 public IPv6 networks. We are however seeing things like this in the openvpn status log:

2a0c:e300:4:14::125eC,XXX,YYY,Sat May 2 15:09:00 2020
2a0c:e300:4:14::12b7C,XXX,YYY,Sat May 2 15:08:37 2020
2a0c:e300:4:14::2e76C,XXX,YYY,Sat May 2 15:09:15 2020
2a0c:e300:4:14::567aC,XXX,YYY,Sat May 2 15:08:45 2020
2a0c:e300:4:14::675C,XXX,YYY,Sat May 2 15:08:56 2020
2a0c:e300:4:14::68bC,XXX,YYY,Sat May 2 15:09:01 2020
2a0c:e300:4:14::8c15C,XXX,YYY,Sat May 2 15:08:30 2020
2a0c:e300:4:14::944dC,XXX,YYY,Sat May 2 15:09:13 2020
2a0c:e300:4:20::13ddC,XXX,YYY,Sat May 2 15:08:42 2020
2a0c:e300:4:20::28e8C,XXX,YYY,Sat May 2 15:09:19 2020
2a0c:e300:4:20::330eC,XXX,YYY,Sat May 2 15:09:23 2020
2a0c:e300:4:20::35a3C,XXX,YYY,Sat May 2 15:08:29 2020
2a0c:e300:4:20::3c44C,XXX,YYY,Sat May 2 15:09:10 2020
2a0c:e300:4:20::4017C,XXX,YYY,Sat May 2 15:09:07 2020
2a0c:e300:4:20::46b3C,XXX,YYY,Sat May 2 15:08:34 2020
2a0c:e300:4:20::46c2C,XXX,YYY,Sat May 2 15:08:53 2020
2a0c:e300:4:20::46cdC,XXX,YYY,Sat May 2 15:08:48 2020
2a0c:e300:4:20::9c56C,XXX,YYY,Sat May 2 15:08:53 2020
2a0c:e300:4:20::b285C,XXX,YYY,Sat May 2 15:08:45 2020
2a0c:e300:4:20::b5e2C,XXX,YYY,Sat May 2 15:09:22 2020
2a0c:e300:4:20::ccc4C,XXX,YYY,Sat May 2 15:08:54 2020
2a0c:e300:4:20::de87C,XXX,YYY,Sat May 2 15:08:42 2020
2a0c:e300:4:20::ff9C,XXX,YYY,Sat May 2 15:09:06 2020
2a0c:e300:4:96::1da3C,XXX,YYY,Sat May 2 15:08:42 2020
2a0c:e300:4:96::2907C,XXX,YYY,Sat May 2 15:09:21 2020
2a0c:e300:4:96::68cC,XXX,YYY,Sat May 2 15:08:38 2020
2a0c:e300:4:96::69aC,XXX,YYY,Sat May 2 15:08:33 2020
2a0c:e300:4:96::a6a4C,XXX,YYY,Sat May 2 15:09:25 2020
2a0c:e300:4:96::c957C,XXX,YYY,Sat May 2 15:09:12 2020
2a0c:e300:4:96::d312C,XXX,YYY,Sat May 2 15:09:14 2020
2a0c:e300:4:96::f6c8C,XXX,YYY,Sat May 2 15:08:58 2020
2a0c:e300:4:96::fe22C,XXX,YYY,Sat May 2 15:09:03 2020
etc.

i.e. openvpn's routing table is full of single IPv6 entries.

The basic reason for these is that people on the Internet apparently try ping all IP addresses in the /112 subnets. Of course ideally that shouldn't happen, but well, that's the wild Internet and openvpn should be robust against this.

And it happens that there is no use for these, since the routing table already contains:

2a0c:e300:4:14::/64,XXX,YYY,Sat May 2 10:50:07 2020
2a0c:e300:4:20::/64,XXX,YYY,Fri May 1 21:42:43 2020
2a0c:e300:4:93::/64,XXX,YYY,Sat May 2 15:16:04 2020
2a0c:e300:4:96::/64,XXX,YYY,Sat May 2 10:06:00 2020

which already cover all these IPs. openvpn could thus just avoid recording each and every IPv6 of these already-recorded ranges.

Worse, when using --learn-address, these IPs are passed to the script, which may thus leak to routing daemons etc. which consequently get overwhelmed as well...

Samuel

[Gert Döring]

This is the way the internal routing table works - networks get looked up, individual addresses are hashed and next time, accessed via hash directly. In the status log, you can just ignore everything with a "C" at the end of the address.

I wasn't aware that these are passed to --learn-address - that is, indeed, not very useful. Need to look into this.