Project

General

Profile

Bug #3257

IP Alias on CARP IP doesn't work where IP alias above CARP parent in list

Added by Atıf CEYLAN almost 6 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Normal
Category:
Virtual IPs
Target version:
Start date:
10/08/2013
Due date:
% Done:

100%

Estimated time:
Affected Version:
All
Affected Architecture:

Description

I have 300 over IPs in 3 different subnets. I have added 3 different CARP IPs from each subnet. Other IPs on them as IP Alias.
If I want to edit a CARP IP, all of IP Aliases (under this CARP IP) shown as cleared at ifconfig outputs and can't be reach to these IPs a few minutes later. But these IPs shown at list of VIP lists on WebConfigurator.

Associated revisions

Revision 2a5960b0 (diff)
Added by Luiz Souza over 3 years ago

Review of CARP uniqid changes.

It turns out that current CARP implementation is not much different from an IP alias.

This commit converts the IP alias to also use the CARP uniqid scheme, this simplify the code in all other places because now we have only two different cases to deal with:

- A friendly interface name (lan, wan, opt1, etc.);
- A Virtual IP - VIP alias (_vip{$uniqid}) - CARP or IP Alias.

The parent of a CARP is always a friendly interface. The parent of an IP alias can be a friendly interface or a CARP (this is the only case of recursion of a VIP).

This commit removes a few cases where CARP were still considered a interface (the old CARP implementation), fixes all the wrong cases of strpos() being used to detect a VIP address (wont work as it returns '0' which fails when tested as 'TRUE'), review the usage of CARP and IP alias as services bind addresses, fixes general issues of adding and editing VIP addresses.

The following subsystems were affected by this changes:

- IPSEC;
- OpenVPN;
- dnsmasq;
- NTP;
- gateways and gateway groups;
- IPv6 RA;
- GRE interfaces;
- CARP status;
- Referrer authentication.

Fixes (and/or revisit) the following tickets:

- Ticket #3257
- Ticket #3716
- Ticket #4450
- Ticket #4858
- Ticket #5441
- Ticket #5442
- Ticket #5500
- Ticket #5783
- Ticket #5844

History

#1 Updated by Atıf CEYLAN almost 6 years ago

Sorry, affected version is 2.1

#2 Updated by Atıf CEYLAN almost 6 years ago

I have tested now again and saw that problem resource is if CARP Ip is defined after IP Alias (order priority problem), the carp_status.php gives the below error.

Oct 9 03:51:18 pf php: /carp_status.php: The command '/sbin/ifconfig '' inet '192.168.1.20'/'24' alias' returned exit code '1', the output was 'ifconfig: interface does not exist

#3 Updated by R. S. almost 6 years ago

How to reproduce this:
I ran into this bug when I modified a setup pulled in from PFSense 2.0.x that looked like this:
(13 PARP VIPs bound to WAN)
(2 CARP VIPs, LAN and WAN)
(2 PARP VIPs, bound to WAN)

I edited/transformed the PARPs into IPAlias VIPs bound to the CARP WAN gateway, and then had a VIP list that looked like this:
(13 IPAlias VIPs, bound to CARP WANgw)
(2 CARP VIPs, LAN and WAN -- unchanged from 2.0.x)
(2 IPAlias VIPs, bound to CARP WANgw)

The result was that two of my IPaliases worked, and 13 did not bind to the CARP VIP, probably because of the reason Atif mentioned above.

If I create a new CARP alias, it's added at the bottom of the VIP list, so getting all CARP VIP interfaces to work correctly would mean deleting and re-adding all of the IPAlias rules!


So this bug hints at two problems:
1. IPaliases can't be declared before a CARP VIP, which isn't really a problem, because the network stack is working as designed...
2. Order in the PFSense VIP list matters to the IPAlias type (possibly others), and either PFSense should order VIPs properly, or allow the user to do so in the GUI interface. Personally, I'd prefer the former.

#4 Updated by Chris Buechler almost 4 years ago

  • Subject changed from IP Alias over CARP IP problem to IP Alias on CARP IP doesn't work where IP alias above CARP parent in list
  • Category set to Virtual IPs
  • Status changed from New to Confirmed
  • Affected Version set to All

wouldn't have to re-create everything in that circumstance, could just manually edit the config to change the order. Not a common circumstance, but one that should work.

#5 Updated by Jim Thompson over 3 years ago

  • Assignee set to Luiz Souza
  • Target version set to 2.3

#6 Updated by Luiz Souza over 3 years ago

  • Status changed from Confirmed to Resolved
  • % Done changed from 0 to 100

Fixed in 2.3 as part of CARP uniqid fixes.

#7 Updated by Chris Buechler over 3 years ago

  • Status changed from Resolved to Feedback
  • Assignee changed from Luiz Souza to Chris Buechler

to me to confirm

#8 Updated by Chris Buechler over 3 years ago

  • Status changed from Feedback to Resolved

works

Also available in: Atom PDF