Selection of Carp Adresses in ipsec

[rkirmis]

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[+] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md

[+] I have searched the existing issues and I'm convinced that mine is new.

Describe the bug
If there are more than one CARP IPs defined, the selection box for the ipsec phase 1 interface
only lists the last entry of CARP IPs for that Interface. The other IPs are not in the list.

To Reproduce
Steps to reproduce the behavior:

1. Add 2 Carp IPs on WAN Interface
2. Edit IPSEC Tunnel Phase 1
3. Select IP Addresse

Expected behavior
All Carp IPs are in the list and selectable

Screenshots

Relevant log files

Additional context
A VPN use an virtual IP as VPN interface.
I have defined for the WAN interface multiple virtual IPs.
The IP written in /usr/local/etc/ipsec.conf is the last defined virtual WAN IP in Firewall -> Virtual IP -> Settings (not that one display in VPN->IPsec->Tunnel Settings->Phase 1)
It’s mandatory that we can choose in VPN settings every virtual IP defined and not randomly one from WAN interface

Path to file
/vpn_ipsec_phase1.php?p1 (URL)
/usr/local/etc/ipsec.conf (File path)

Environment

OPNsense 19.7.4_1 (amd64, LibreSSL)

[ampfinger]

I have got the same problem here. Multiple virtual WAN addresses but can only choose one WAN address in ipsec phase 1 definition.
And the shown WAN address isn't the one which is entered in ipsec.conf, instead it is the last virtual WAN address in Firewall - Virtual IPs.
I can provide screenshots if necessary.

[rkirmis]

Whta can i do, to complete the issue?
How do i get the incomplete flag removed?

[mimugmail]

Screenshot would be a good start. Today I helped a customer with latest 19.7.5_5 and around 20 CARP aliases where everyone was selectable ...

[Kimotu]

I am on 19.7.6 and having a similar issue. But since running IPv6 configuration, I can confirm that with IPv6, the expected behavior works. All IPv6 CARP addresses get listed. Just IPv4 CARP adresses are missing.

Here a list what is listed and selectable:

• interface address (ipv4) (the physical one when you select an interface, WAN, LAN, ...)
• IPv4 IP-Aliases
• IPv6 IP-Aliases
• IPv6 CARP-Adresses

Not listed:

• IPv4 CARP addresses

Not even one IPv4 CARP adress is listed.

[AdSchellevis]

Same interface and same vhid used multiple times? (for the missing ones)

That would be the only thing I can think of looking at the code.

core/src/etc/inc/util.inc

Line 866 in b2560c6

$iflist["{$vip['interface']}_vip{$vip['vhid']}"] = $vip['subnet'];

^^ can't cope with overlap

[Kimotu]

Hi, yes ipv6 and ipv4 use same VHID per interface. Kind regards, Kimotu Bates Ad Schellevis <notifications@github.com> schrieb am Fr., 22. Nov. 2019, 18:33:

…

Same interface and same vhid used multiple times? (for the missing ones) That would be the only thing I can think of looking at the code. https://github.com/opnsense/core/blob/b2560c6eb46e2739a33c8e761db2b9efe541b776/src/etc/inc/util.inc#L866 ^^ can't cope with overlap — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3732?email_source=notifications&email_token=AK2JL6TJMUNA6O243CCZMUTQVAJVNA5CNFSM4I3O4QV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE6KL3Y#issuecomment-557622767>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK2JL6VDA76IG2TZVP7VJGDQVAJVNANCNFSM4I3O4QVQ> .

[AdSchellevis]

ok we need to check the callers of get_configured_carp_interface_list() then, one tip for future issue tracking, try to be very specific about what's configured and how you expect it to appear (details matter a lot in these cases).

[AdSchellevis]

There won't be an easy fix for this without breaking existing configurations or needing changes to existing setups. Since the schema [interface]_vip[hid] isn't unique and stored in multiple places.

Marked the ticket as cleanup for now, it's an omission in the system, a workaround could be to use separate vhid's in cases you want to use them for binding.

[AdSchellevis]

looking at the validations again, you shouldn't be allowed to add more than one carp vhid on an interface. 754d483 Intended use is to use aliases for the non-primary one (which also prevents trying to set the password several times on the same interface).

[Kimotu]

Within the same address family, I do use ip aliases. One ipv4 carp, rest aliases. But I don't see an ipv6 address as alias for an ipv4 address. Although the carp mechanism differs. Ipv6 uses protocol 112, ipv4 multicast. Kind regards, Kimotu Bates Ad Schellevis <notifications@github.com> schrieb am Sa., 23. Nov. 2019, 10:08:

…

looking at the validations again, you shouldn't be allowed to add more than one carp vhid on an interface. 754d483 <754d483> Intended use is to use aliases for the non-primary one (which also prevents trying to set the password several times on the same interface). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3732?email_source=notifications&email_token=AK2JL6RCVQTTWJCRGMLHXODQVDXHJA5CNFSM4I3O4QV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE7Q56A#issuecomment-557780728>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK2JL6U5IPFB22KPW4IMV7DQVDXHJANCNFSM4I3O4QVQ> .

[AdSchellevis]

since the internal key is per interface+vhid it won't support overlap, the previous bug (754d483) allowed such entries to be made. Changing this would probably mean to support ip aliases with a vhid in these selections and add some sort of key to identify them, but unfortunately this probably involves quite some work to fix a pattern that's already quite flawed (mixing interfaces and addresses).

[AdSchellevis]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository,
please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.