GET INST BY VIRT error is too obscure quiet

[gcc]

This error means that your packets are being dropped:

Tue Sep 20 12:47:53 2011 us=236940 GET INST BY VIRT: 196.12.12.88 [failed]

Unfortunately it's very easy to miss. It's not visible at debug level 6 and it's not obvious at all. Perhaps it could be made more severe, and say something like:

"No internal route (iroute) to 196.12.12.88, dropping packet, see ​http://openvpn.net/index.php/open-source/faq/79-client/317-qmulti-bad-source-address-from-client--packet-droppedq-or-qget-inst-by-virt-failedq.html"

Cheers, Chris.

[Samuli Seppänen]

Agreed, does the error message mean "GET INST[ANCE] BY VIRT[UAL] [SOMETHING]"? Very obscure in my opinion, and worth fixing.

According to the ​FAQ entry both multi errors are triggered by the same problem (missing iroute), so the suggested error message is probably correct.

[Gert Döring]

I wonder why this is not triggering the (much more visible)

Jan 8 21:44:42 server ovpn-tun99[909]: client-xx/80.145.x.x MULTI: bad source address from client [fe80::7498:59f4:60a0:eba1], packet dropped

message... maybe this was already rewritten for 2.2 to make it more easily understandable?

So what we need to do is "see what error message is triggered in the iroute scenario on 2.3.2", and if it's not the MULTI message, fix it for 2.3.3 - and otherwise, close it.

Samuli, can you test? I'll fix, if needed.

[Gert Döring]

Did some staring-on-code today, this is actually not quite the same as"MULTI: bad source address" - this code (multi.c, multi_get_instance_by_virtual_addr()) can be called for "tun->client", "client->tun", and "client->client", checking source address (in which case a failure to match will will print the "MULTI: bad source" message), or dest address, respectively.

Samuli, could you update the FAQ entry on this? This is not fully correct today, if it claims "it's the same thing".

Making this message more prominent is actually not something we should do lightly - it will be seen quite frequently if a client is not connected, and someone sends packets there, like "a port scan coming from the Internet" (not unusual) we'll flood the server logs. Worse, this message is actually triggered for every packet coming *from* a client that is not going to a different client but to the fallback = the tun interface.

One *could* add (like it's done for "MULTI: bad source") a separate message for the tun->client case ("MULTI: no instance found for IP ...."), but even then it should not get a higher verbosity level, for the reasons mentioned. This would be something for 2.4, if at all.

What we could do for 2.3.3 is to reword the message - but then, with the appropriate FAQ entry, it actually is quite clear. So I'd prefer to update the FAQ, and not change the code here.

[Samuli Seppänen]

Three years later... cron2: does your analysis still hold? The FAQ is now user-editable, so perhaps you would be the more correct person to edit the item in question?