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
networkstatement 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.
-
@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
networkstatement 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?
-
-
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.
-
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!
-
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.
-
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
-
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. -
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-STABLEPFBlocker-NG:
pfBlockerNG-devel net 2.2.5_37FRR:
frr net 0.6.8_7If 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
-
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
-
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. -
"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....
-
@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.
:) -
you are right we need more info.
-
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.
-
@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
-
Hi @all
doin the right changes, seems to work, ... .. .
OSPF is still running correctly, even after a reboot.
many thanx 4 hlp
regards Thiamata
-
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)
