FRR 0.6.3 OSPF seems to break with IP aliases

freph533

@jimp said in FRR 0.6.3 OSPF seems to break with IP aliases:

IMO, the pfBlocker VIP should be on localhost, not LAN. The traffic still arrives at the firewall that way, and it will answer it fine from any interface. I'm not sure why they'd recommend keeping it there vs localhost.

You really shouldn't have multiple subnets on a single interface if you can avoid it.

While the old network statements may have masked the issue, it's ultimately a design problem with the setup that should be corrected.

While I agree that it's odd, the issue still exists that a VIP on an OSPF interface will break it. Any workarounds other than to just not use a VIP on an OSPF interface (not an adequate solution IMO, others may disagree), or is it a legitimate issue? Secondary IP addresses exist on standard networking hardware and still work fine with OSPF as far as I'm aware, though normal subinterfaces are generally not the interface itself, but int.#.

jimp

FreeBSD doesn't have a concept of "subinterfaces" in that way. There are VLANs, naturally, but that's a different concept.

There may be a general issue with FRR and additional interface addresses using a /32 mask, as it fails with the same error message even with a VIP in the same subnet as the interface address with a /32 mask. The network statement wouldn't help with that scenario.

If there is a VIP in the same subnet as the interface with the same mask as the interface address, it works fine. If there is a VIP in a different subnet with a normal (non-32) mask, it works fine.

I'd open a bug report upstream with FRR directly and see what they have to say about it, but again, moving the /32 VIP to localhost should be fine in theory. Or changing the VIP mask to something that is an actual subnet, not a single address.

freph533

@jimp said in FRR 0.6.3 OSPF seems to break with IP aliases:

FreeBSD doesn't have a concept of "subinterfaces" in that way. There are VLANs, naturally, but that's a different concept.

There may be a general issue with FRR and additional interface addresses using a /32 mask, as it fails with the same error message even with a VIP in the same subnet as the interface address with a /32 mask. The network statement wouldn't help with that scenario.

If there is a VIP in the same subnet as the interface with the same mask as the interface address, it works fine. If there is a VIP in a different subnet with a normal (non-32) mask, it works fine.

I'd open a bug report upstream with FRR directly and see what they have to say about it, but again, moving the /32 VIP to localhost should be fine in theory. Or changing the VIP mask to something that is an actual subnet, not a single address.

Makes sense that FreeBSD works that way. I may have to open a bug report with FRR since this definitely does not work with pfBlocker natively if you only have a WAN and a LAN interface since localhost cannot even be set as the listening port in DNSBL (or WAN for that matter; I only have my VPN interface and LAN available). Trying to add a CIDR prefix ends up in the VIP address looking like "10.10.10.1/24/32", so it's hardcoded to be a /32 it seems.

You can manually change what the VIP binds to in the VIP settings, but it automatically changes back to what's set in DNSBL any time a sync is performed.

@BBcan177 any ideas on this one? What's your POV as the pfBlocker dev?

pete35

@freph533
@BBcan177

Is there any news to that problem? Im running into this today on frr vers: 0.6.7_3 and pfblocker 2.2.5_33 on pfsense 2.5.4_1.

jimp

I haven't heard of anything changing with it. But it's not an issue we can fix in pfSense or FRR. Maybe if pfBlocker added a way to set the VIP subnet mask or interface, though /32 is normal, using another mask or putting the VIP on localhost should work around the FRR issue.

pete35

i got a message from bbcan:

Is fixed in the next upcoming release of pfBlockerNG-devel:

Edit:

/usr:local/www/pfblockerng:pfblockerng_dnsbl.php

As per this link, add the line in red below line 372:

https://github.com/pfsense/FreeBSD-ports/blob/devel/net/pfSense-pkg-pfBlockerNG-devel/files/usr/local/www/pfblockerng/pfblockerng_dnsbl.php#L372

$interface_list = pfb_build_if_list(FALSE, FALSE);

$interface_list = array_merge(array('lo0' => 'Localhost'), $interface_list);]

$int_size = count($interface_list) ?: '1';

after a reboot it is working now ....

thanks to bbcan and jimp!

freph533

@pete35

Good to know that it's fixed upstream. l know I had to make the change in 2.2.5_33 so maybe it's fixed in 2.2.5_34.

thiamata

Hello

Somehow it seems to work (for a moment) and somehow not.

I can select for the VIP interface switch it from LAN to locaclhost, then my OSPF-Enviroment works fine. All other features seems also to work fine, but after a certain time the system itself reverts the interface from localhost back to LAN.

10/25/20 00:09:36 	21.0 	229 KiB 	(system): pfBlockerNG: saving DNSBL changes 	Current configuration
	10/24/20 23:18:53 	21.0 	229 KiB 	admin@a.b.c.d (Local Database): Saved/edited a virtual IP.

I am not sure where is my mistake, ... .. .

Thanx4hlp

regards thiamata

pete35

Did you really save it? Did you check that it is changed to localhost after saving it? Maybe the gui has some glitches there.
Is it already set to localhost after a full update/reload of pfblocker/dnsbl?
I cant see this behavior on my pfsense systems.

thiamata

yes, I saved it. (shown in the Log snip, ... .. .)

Then my OSPF works fine and correct, but after a certain (round about 30 min) the systems reverts back to LAN, OSPF failed.

maybe more details can help:

Versions I am using, but I am trying to fix this for longer time.
(I had the same Probs running 2.4 and the Blocker not running on DEVEL and also on older versions of FRR)

PF:
2.5.0-DEVELOPMENT (amd64)
built on Sat Oct 31 01:00:13 EDT 2020
FreeBSD 12.2-STABLE

PFBlocker-NG:
pfBlockerNG-devel net 2.2.5_37

FRR:
frr net 0.6.8_7

If it is set to LAN, my switch receives OSPF advertisement from 10.10.0.1, which seems to the default VIP for the DNSBL interface and not from the configured VLAN-Interface.

After switching to localhost and doing a restart of both OPSF processes (Routing-Switch and PFsense), OSPF reaches the full adjacency state. This works so long fine until the PFsense itself (system) changes the interface setting back to LAN, then during the next advertisement cycle OSPF falls back to INIT/unkwon on my Switch. On my PFsense the OSPF-Process is still running, but now again using the wrong IP-Interface for sending advertisements.

For me this looks like a setting mistake which is activated, something like auto-cfg-recovery, but I cannot find this kind of setting anywhere.
-Or-
It is to be a kind of bug. It seems to the PF is using the first IP-Interface of a Interface to send advertisements.
(I found a similar bug on the 5800er Switches Comware based from HPE some years ago in an older Version, if you activate the BFD feature the automatic generated Route-ID for OPSF/BGP is not using the interface IP, it is using the BFD IP. The was a bug, using the IP with a higher internal Prio. This behaviour is very similar)

At the moment I maybe have to go back to static routing, but, ... .. .

If I can help with further details, let me know.

regards Thiamata

thiamata

new try,

I have changed the interface again to localhost, saved it and created a backup.
Compared this backup with another one and figured out settings in are correct with "lo0" and not LAN.

Doing a reset to my pfsense and restored the backup (the one with lo0)
reboot the pfense to activate the restored config, ... .. .

All other settings are correct, except this lo0 is changed back again to LAN.

any other ideas, ... .. .

Maybe at the end I have to set it up new from scratch.

(But I will understand what I have done wrong, so reinstall fixes maybe the Symptom, but not the problem)

regards Thiamata

vito

@thiamata

Make sure you edit pfblockerng_dnsbl.php on all your PF boxes with the line from pete35's post on 9/5/2020

Example:
after line 372
add another line (373) with
$interface_list = array_merge(array('lo0' => 'Localhost'), $interface_list);

save the file, restart pfb services, you should now see localhost in the available options for the web server.
Force a reload, it should stick.

It does not look as if this made it in 2.2.5_37, so if you reinstall or update to another build that does not have the fix, this may not stay.

Any word when this will make it into a new release?

NOTE: if i am wrong with the steps above pls let me know.
Thanks to all for the great info.

pete35

"localhost" wouldnt be there, if it wasnt edited correctly. The problem is, why it changed automagically back to LAN. I have serveral pf boxes where it stays at "localhost" , so it shouldnt be a general problem. Maybe some sync of dnsbl or pfblocker settings is configured ... or the reload of lists is trigering that....

vito

@pete35
Agree.
But this statement from thiamata seems to indicate (possibly) he changed the VIP which has the localhost option no mater what.

"I can select for the VIP interface switch it from LAN to locaclhost"

Changing the VIP and not changing pfblockerng_dnsbl.php will produce the symptom being described on next PFB reload. (Tested and got the same result) (note to all: don't change pfB DNSBL VIP by hand per the comment in the description field) :)

In PFb, the option is called "Webserver Interface" that would need to be changed after the fix to pfblockerng_dnsbl.php and not "VIP".

not sure..but i will put this out there just in case.

again, thanks for the leg work on this.
:)

pete35

you are right we need more info.

A Former User

I worked this issue around by assigning pfblockerNG VIP to an OSPF Passiv Interface. This way the pfbng VIP address will be propagated through OSPF in your Network and you don't have a problem building OSPF adjacency.

But yes - it would be better pfblockerNG uses a loopback Interface in the first place.

thiamata

@pete35 said in FRR 0.6.3 OSPF seems to break with IP aliases:

$interface_list = array_merge(array('lo0' => 'Localhost'), $interface_list);]

It seems that I have done changes at the wrong place, or maybe not, ... .. .

I believe the ] at the end is a sign too much.
;-)
But now it is getting another kind of weird.

After the reboot (and without ] at the end in line 372) my pf comes up correctly, it seems so.

Yes , now the webserver interface is correct with lo0 and also the VIP interface is set to lo0.

But my OSPF setup on Router still hangs in INIT phase.

After switching the VIP to LAN (saving) and back lo0 (saving)

the OSPF adjacencies went to FULL.

Lets wait if OSPF went down after a certain time, ... .. .

I will let you know it.

Many thanx for this great support.

regards Thiamata

thiamata

Hi @all

doin the right changes, seems to work, ... .. .

OSPF is still running correctly, even after a reboot.

many thanx 4 hlp

regards Thiamata

viktor_g

not an issue anymore https://forum.netgate.com/topic/158592/pfblockerng-devel-v3-0-0-no-longer-bound-by-unbound:
CHANGELOG:

Add Localhost at the default DNSBL Listening interface
(Suggest all existing users change to this interface)