Opened 4 years ago

Last modified 3 years 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: tct, Antonio Quartulli

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 4 years ago by tct

Cc: tct added

comment:2 Changed 4 years ago by Gert Döring

Cc: Antonio Quartulli 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 4 years ago by Gert Döring

Milestone: release 2.5release 2.5.3

comment:4 Changed 3 years ago by Gert Döring

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