FRR 0.6.3 OSPF seems to break with IP aliases

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)