Project

General

Profile

Actions

Feature #12055

open

Option to disable XMLRPC Sync for Loopback Virtual IPs

Added by Chris Myles 3 months ago. Updated 3 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
Virtual IP Addresses
Target version:
-
Start date:
06/17/2021
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default

Description

According to this pfSense doc, Loopback IPs are synchronized via XMLRPC because they are only ever active on the local machine and therefore cannot conflict with each other on multiple nods. However, this is not actually true. If you add a loopback IP into routing as a /32 network, it is capable of receiving traffic from any host on the network just like any other address is. I use this model to configure management interfaces for my firewalls so it would be helpful to have an option to disable XMLRPC sync for specific virtual IPs so that they don't conflict.


Files

cisco route.png (45.2 KB) cisco route.png Cisco routing table with static route for pfSense loopback Chris Myles, 06/18/2021 08:16 AM
loopback.png (242 KB) loopback.png loopback config Chris Myles, 06/18/2021 08:16 AM
ping and tracert.png (28.9 KB) ping and tracert.png connectivity test from my desktop to pfsense loopback address Chris Myles, 06/18/2021 08:16 AM
gui access via management.png (316 KB) gui access via management.png accessing GUI via loopback address Chris Myles, 06/18/2021 08:16 AM
pfsense route.png (124 KB) pfsense route.png pfsense routing table Chris Myles, 06/18/2021 08:16 AM
Actions #2

Updated by Jim Pingle 3 months ago

  • Status changed from New to Feedback

While it is capable of receiving traffic from another host, nothing could ARP for it, so it can't "conflict" as other VIP types could (IP alias on a regular interface, CARP, or proxy ARP). It could be a source of traffic but if that's the problem you can just not choose it as a source on the secondary for whatever daemon you're using it with.

Can you describe in more detail the problem scenario and exactly what sort of conflict you are seeing?

Actions #3

Updated by Chris Myles 3 months ago

The problem is that when you configure a loopback address, it's considered a directly connected network and will be advertised by dynamic routing protocols. This makes it a simple yet scalable solution for device management, but it also results in a conflict as both the primary and standby devices will advertise routes for it which makes it impossible to target an individual device. I'm seeking a way to make loopback addresses unique to a particular device in the same way a physical interface address is.

My current workaround has been to disable Virtual IP sync but that also means that CARP addresses are not synced which causes issues when selecting a CARP address in an interface selection dropdown. At the moment I'm using static routing within my network but I'm planning on deploying OSPF which will distribute the loopback address as a /32 route.

Actions #4

Updated by Jim Pingle 3 months ago

Use the features built into the dynamic routing protocols to prevent those addresses from being advertised. That's the purpose of things like route-maps and distribute lists in the OSPF settings near the advertise options.

Actions #5

Updated by Chris Myles 3 months ago

They should be advertised though as the loopbacks serve as the primary management addresses for their corresponding node. The point I'm getting at is that there are scenarios in which loopback addresses should be able to accept traffic from outside of the device, at which point the address must obviously be unique on the network since every IP accessible on a network must be unique to avoid routing conflicts. According to the pfSense documentation I linked, non-loopback IP aliases are not synced between nodes for this exact reason. I'm just asking for that functionality to be extended to loopback addresses through the use of a "disable XMLRPC sync" option.

Actions #6

Updated by Jim Pingle 3 months ago

Then set FRR differently on each node so it only advertises the addresses you want from each node. FRR does not support XMLRPC so there is no problem doing that.

I get what you're after but I don't think it's the right or proper solution for addressing the root cause here.

Actions #7

Updated by Chris Myles 3 months ago

That seems unnecessarily complex and counter-intuitive. If I go that route then I have a routable IP address on two devices at once and I'm relying on routing config to blacklist the advertisement of the IP that doesn't belong to the device.

It would make more sense to me to either add an option to block XMLRPC sync, or modify XMLRPC sync to not sync routable IP aliases regardless of the interface they live on (i.e. a 127.x address on loopback would sync, but an RFC1918 address would not).

Actions #8

Updated by Jim Pingle 3 months ago

Changing the sync default behavior would be a POLA violation as it would break users who rely on that behavior now.

For how the vast majority of users implement things, it works as-is and there are plenty of users relying on that already.

We could maybe add an option on VIPs to not sync a specific VIP, but like with rules you get into a problem where that lets you have an entry on the primary which differs but it does not protect items on the secondary which will be clobbered by the sync. It's nowhere near as simple as just adding a checkbox.

You have several valid ways to implement the design you have chosen. That you do not like them does not make them less valid.

Actions

Also available in: Atom PDF