Opened 2 years ago

Last modified 19 months ago

#1047 new Bug / Defect

ifconfig_remote environment variable not passed to --up script

Reported by: kir-pich Owned by:
Priority: major Milestone:
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 (4)

comment:1 Changed 2 years ago by selvanair

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 2 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 2 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 19 months ago by Antonio

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

Note: See TracTickets for help on using tickets.