The parsing of the status file for the tunnel client IP makes some assumptions on the order of the lines containing the peer address; those are false in the case of a subnet configured under the [..., 'server', 'client'] tagnode. This will be fixed in the rewrite in T4770 for Sagitta, and in the original for Equuleus.
Details:
For the config fragment:
```
>>> conf = Config()
>>> d = conf.get_config_dict(["interfaces", "openvpn", "vtun10", "server"], get_first_key=True)
>>> pprint(d)
{'client': {'client1': {'ip': ['10.10.0.10']}},
'max-connections': '250',
'subnet': ['10.10.0.0/24'],
'topology': 'subnet'}
```
the status file is as follows:
```
jestabro@vyos:~$ sudo cat /run/openvpn/vtun10.status
OpenVPN CLIENT LIST
Updated,2022-12-10 21:32:34
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
client1,98.212.152.242:55733,8609,8502,2022-12-10 21:11:12
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.10.0.10,client1,98.212.152.242:55733,2022-12-10 21:11:12
GLOBAL STATS
Max bcast/mcast queue length,0
END
```
The parsing for tunnel ID correctly find this in lines[1], for the list of lines containing "client1".
However, for config fragment (tautological example):
```
>>> conf = Config()
>>> d = conf.get_config_dict(["interfaces", "openvpn", "vtun10", "server"], get_first_key=True)
>>> pprint(d)
{'client': {'client1': {'ip': ['10.10.01.10'], 'subnet': ['10.10.02.0/245']}},
'max-connections': '250',
'subnet': ['10.10.01.0/24'],
'topology': 'subnet'}
```
the status file is:
```
jestabro@vyos:~$ sudo cat /run/openvpn/vtun10.status
OpenVPN CLIENT LIST
Updated,2022-12-10 20:52:542:07:36
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
client1,98.212.152.242:51618,5534,54270574,5452,5362,2022-12-10 20:44:082:01:33
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.10.0.0/241.10,client1,98.212.152.242:516180574,2022-12-10 20:44:082:03:13
10.10.0.102.0/25,client1,98.212.152.242:516180574,2022-12-10 20:44:082:01:33
GLOBAL STATS
Max bcast/mcast queue length,0
END
```
and getting lines[1] will give the incorrect entry. Consequently, we will filter out the subnet lines before looking for the tunnel IP.