Feature #12055
closed
Option to disable XMLRPC Sync for Loopback Virtual IPs
0%
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 | ||
| loopback.png (242 KB) loopback.png | loopback config | ||
| ping and tracert.png (28.9 KB) ping and tracert.png | connectivity test from my desktop to pfsense loopback address | ||
| gui access via management.png (316 KB) gui access via management.png | accessing GUI via loopback address | ||
| pfsense route.png (124 KB) pfsense route.png | pfsense routing table |
Updated by Chris Myles almost 2 years ago
Forgot the doc link - here it is: https://docs.netgate.com/pfsense/en/latest/firewall/virtual-ip-addresses.html
Updated by Jim Pingle almost 2 years 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?
Updated by Chris Myles almost 2 years ago
- File cisco route.png cisco route.png added
- File loopback.png loopback.png added
- File ping and tracert.png ping and tracert.png added
- File gui access via management.png gui access via management.png added
- File pfsense route.png pfsense route.png added
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.
Updated by Jim Pingle almost 2 years 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.
Updated by Chris Myles almost 2 years 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.
Updated by Jim Pingle almost 2 years 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.
Updated by Chris Myles almost 2 years 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).
Updated by Jim Pingle almost 2 years 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.