Opened 14 months ago

Last modified 18 hours ago

#1279 new Bug / Defect

openvpn spuriouslyk records each and every used IPv6 of the range

Reported by: sthibault Owned by: Gert Döring
Priority: major Milestone: release 2.5.4
Component: IPv6 Version: OpenVPN 2.4.7 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: tincantech, Antonio

Description

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

Change History (4)

comment:1 Changed 11 months ago by tincantech

Cc: tincantech added

comment:2 Changed 10 months ago by Gert Döring

Cc: Antonio added
Milestone: release 2.5

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.

comment:3 Changed 3 months ago by Gert Döring

Milestone: release 2.5release 2.5.3

comment:4 Changed 18 hours ago by Gert Döring

Milestone: release 2.5.3release 2.5.4
Note: See TracTickets for help on using tickets.