Opened 3 years ago

Last modified 5 months ago

#1047 reopened Bug / Defect

ifconfig_remote environment variable not passed to --up script

Reported by: kir-pich Owned by:
Priority: major Milestone: release 2.6
Component: Generic / unclassified Version: OpenVPN 2.4.5 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

I can see variables like:

ifconfig_ipv6_remote
ifconfig_ipv6_netbits
ifconfig_ipv6_local
ifconfig_broadcast
ifconfig_netmask
ifconfig_local

but there's no ifconfig_remote passed to my --up script.

OpenVPN config:

dev t-a-chara
remote 109.232.227.132 1194
config "airvpn.inc"

Included file:

resolv-retry infinite
nobind
persist-key
persist-tun
route-delay 5
verb 3
explicit-exit-notify 5
ca        "../auth/airvpn-ca.crt"
cert      "../auth/airvpn-user.crt"
key       "../auth/airvpn-user.key"
tls-auth  "../auth/airvpn-ta.key" 1
remote-cert-tls server
cipher AES-256-CBC
comp-lzo no
proto udp

client
dev-type tun
pull-filter ignore redirect-gateway
script-security 2
up "../update-netns.py"

Change History (15)

comment:1 Changed 3 years ago by Selva Nair

I think this is a side effect of how topology subnet was implemented (similar to TAP in addressing semantics). In this case virtually there is a subnet reachable through the tunnel and there is no single remote. This is also clear from the syntax of --ifconfig in subnet topology. A bogus ifconfig_remote could have been constructed (say, some address within the subnet, preferably that of the server when possible), but that's not done -- at least not exposed to the user.

In scripts I usually use route_vpn_gateway as the remote, although it may not match the actual address of the remote end.

comment:2 Changed 3 years ago by kir-pich

Is the topology implementation different for IPv4 and IPv6? For IPv6 the remote address is visible.

In my case route_vpn_gateway is also invisible, probably because I ignore the default route. I wish to save the gateway for later use.

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

IPv6 does not have --topology variants and the historical baggage tied to it. So, yes, IPv6 is different - IPv6 is always "subnet".

comment:4 Changed 3 years ago by Antonio

@cron2 is this really a bug or something that could be handled better?

comment:5 Changed 12 months ago by Gert Döring

IPv4 is a mess. We should just get rid of --topology and always do "subnet". But getting there is non-trivial.

But Selva has described it quite well, I think - there is no "remote" in subnet mode, but actually "lots of remotes in the subnet". Anyone of those will do for routing setup.

@kir-pich: what is it that you are trying to achieve? Routes can also be pointed to the tunnel interface (at least on Linux), which is nicer than "to an IP address" anyway.

comment:6 Changed 12 months ago by kir-pich

Looking back at the scripts that were used at the time:

command = IP + ' -6 route add default via ' + ipv6_gate + ' dev t-' + config_name + ' table ' + table_name

probably you are right and gateway address might be dropped.

comment:7 Changed 12 months ago by Gert Döring

Resolution: worksforme
Status: newclosed

Indeed, that script would just work as well by using "dev $tunXX" :-) (and OpenVPN passes the device name down to --up scripts).

OTOH, you can just do redirect-gateway ipv6 and it will create a default route into the tunnel...

Anyway, I think we can close this - there are ways to achieve what you need, and no more activity needed on our side.

comment:8 Changed 12 months ago by kir-pich

Yes, however config option will create default route in "main" routing table and that was slightly more complex setup — one tun device per dynamic network namespace with veth device + routing between veth & tun.

comment:9 in reply to:  2 ; Changed 5 months ago by OpenNya

Resolution: worksforme
Status: closedreopened

I have the same issue.

Replying to kir-pich:

In my case route_vpn_gateway is also invisible, probably because I ignore the default route. I wish to save the gateway for later use.

According to OpenVPN official documentation (environment variables section):

route_vpn_gateway:
The default gateway used by --route options, as specified in either the --route-gateway option or the second parameter to --ifconfig when --dev tun is specified.

I am absolutely sure that you have a record in the syslog similar to this (just like I have):

openvpn(client2)[31499]: PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,socket-flags TCP_NODELAY,ifconfig 10.8.0.3 255.255.255.0,peer-id 0

That means that the issue you described is a real bug.
Because route-gateway directive was passed to client, but was NOT re-translated to the scrips as a 'route_vpn_gateway' environment variable.

And thus all the arguments given by the developers have absolutely no sense.
Somebody needs to read their own manuals.

comment:10 in reply to:  9 ; Changed 5 months ago by Gert Döring

Replying to OpenNya:

And thus all the arguments given by the developers have absolutely no sense.
Somebody needs to read their own manuals.

Thanks for your friendly words.

Please send a patch to get the desired behaviour, then.

comment:11 Changed 5 months ago by Gert Döring

Milestone: release 2.6

comment:12 in reply to:  10 Changed 5 months ago by OpenNya

Replying to Gert Döring:

Please send a patch to get the desired behaviour, then.

Thank you for your trust in my developer skills. (What?)

But regarding the issue I think it's a regression.

https://community.openvpn.net/openvpn/ticket/676
https://community.openvpn.net/openvpn/ticket/668

I think it would be simpler for you guys to redact OpenVPN reference manual in the part related to route_vpn_gateway and thus any need to patch anything will be eliminated!

Thank you for your help!

comment:13 Changed 5 months ago by OpenNya

Also I can confirm the issue described here persists in the version OpenVPN 2.4.7 I am currently using.

This situation is not so funny as you might have thought.
That's because ver. 2.4.7 is the latest openvpn version in the OpenWRT repository of the currently latest LTS release 19.07.
It could be that many thousands of OpenWRT installations are subject to this bug.

Last edited 5 months ago by OpenNya (previous) (diff)

comment:14 in reply to:  13 ; Changed 5 months ago by Gert Döring

Replying to OpenNya:

It could be that many thousands of openvpn installations are subject to this bug.

So, what does this mean? If we change the manual (as suggested), it's no longer a problem?

Since there was only a single report of that bug, and it hid in a report for a different missing variable (look at the subject of this bug: ifconfig_remote is what this was about, originally), it's not of the category "many thousands of openvpn installations do not work right".

So, yes, manual and code do not agree. You suggest that "fixing the manual" will be good enough - but that suggests that the bug is really not that big of a problem in practice.

Last edited 5 months ago by Gert Döring (previous) (diff)

comment:15 in reply to:  14 Changed 5 months ago by OpenNya

Replying to Gert Döring:

So, yes, manual and code do not agree. You suggest that "fixing the manual" will be good enough - but that suggests that the bug is really not that big of a problem in practice.

I really do not know what was the exact point in time when this issue returns back to 2.4.x code.
Thus I do not know how many systems are affected.

But in my personal case I was unable to correctly set up policy based routing using UP /ROUTE-UP scripts because of absence of route_vpn_gateway parameter.

I have filed a ticket to OpenWRT bugtracker regarding this issue.

https://github.com/openwrt/packages/issues/15444

But It would be impossible for OpenWRT devs to resolve the issue in absence of activity in resolving this issue from OpenVPN devs.

Last edited 5 months ago by OpenNya (previous) (diff)
Note: See TracTickets for help on using tickets.