Question about the BOGON table

johnpoz

I was chatting with Steve and drew his attention to this - he agrees something not right and is looking into it.

johnpoz

@breakaway Looks like they fixed it.

I just forced an update and
Table last updated on Thu Oct 14 04:50:01 2021 GMT. 1,365 records

psp

@johnpoz
Confirmed here. Thanks johnpoz.

breakaway

@johnpoz - confirmed as well, looking good over here!

Table last updated on Thu Oct 14 04:50:01 2021 GMT. 1,365 records.

Thanks for the assistance.

bingo600

@johnpoz

I'm not getting any updates on Diagnostics -> Tables -> Bogons , and press update ... Seems like it just times out.

still on

Table last updated on Fri Aug 20 04:50:01 2021 GMT.     1,370 records.

Hmm ....
I can access the "source" file from my Laptop ...

But on the pfSense it seems to hang here

ps aux | grep -i bogon
root    70221   0.0  0.0   6976   2728  -  I    17:49    0:00.01 /bin/sh /etc/rc.update_bogons.sh now
root    72230   0.0  0.1   9304   6012  -  I    17:49    0:00.05 /usr/bin/fetch -a -w 600 -T 30 -q -o /tmp/bogons https://files.pfsense.org/lists/fullbogons-ipv4.txt
root     8734   0.0  0.0   6560   2292  0  S+   17:58    0:00.00 grep -i bogon

Is this a 2.4.5-p1 issue ??

MoonKnight

@bingo600

Hit update then.

bingo600

Yuckk

/usr/bin/fetch -a -w 600 -T 30 -q -o /tmp/bogons https://files.pfsense.org/lists/fullbogons-ipv4.txt
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
34374270280:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:/build/ce-crossbuild-245/sources/FreeBSD-src/crypto/openssl/ssl/s3_clnt.c:1269:
fetch: https://files.pfsense.org/lists/fullbogons-ipv4.txt: Authentication error

Is that the "Expired letsencrypt cert"

Continued here
https://forum.netgate.com/topic/167276/can-t-update-bogons-on-a-2-4-5-p1-cert-expired

Vollans

My show tables shows bogons, but doesn't show the bogonsv6 table. Any idea why?

Gertjan

@vollans

You will need WAN type interface that has the "bogons" checked :

When upgrading the bongon tables manually, like :

/etc/rc.update_bogons.sh 1

you see some log line :

and a table bogonsv6 is created :

see also the file :

-rw-r--r--  1 root  wheel  2071417 Oct 18 08:20 bogonsv6

this file is very big (IPv6 is 'big').

See the file /etc/rc.update_bogons.sh for several reasons why the loading of the bogonsv6 can fail. These message will also figure in the system log (see above).

breakaway

Hi,

Perhaps I spoke too soon? I have some older pfSense systems I look after as well. One is 2.4.4, the other is 2.4.5

Neither can update bogons. Stuck on the Friday, 20 Aug

I tested dns lookup and port 80 connectivity to files.pfsense.org, and those succeeed.

For now, I have added https://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt as an alias and setup a manual block rule on the WAN.

Edit It looks like this may be related to the version of pfSense. I updated the Bogons_v6 table on my router here in the lab which is running 2.5.2 and that has now updated successfully. But the other two (2.4.4/2.4.5) will not.

Is this a conscious decision to not support older releases?

bingo600

@breakaway
I had the same issue on a 2.4.5-p1
https://forum.netgate.com/topic/167276/can-t-update-bogons-on-a-2-4-5-p1-cert-expired

You would need a "ssh drivers license" to fix it

/Bingo

johnpoz

@breakaway said in Question about the BOGON table:

Is this a conscious decision to not support older releases?

What OS maker or even Software maker supports ALL previous versions? At some point they drop support for older versions. This always done.. Can you call MS and get support for windows 95? ;) Maybe if you pay them enough $$ ;) hehehe But it is not officially supported.

Pfsense has always been this way, as new versions come out - they drop support for the older versions. While back in the day you use to be able to download the older versions, even if not supported. They stop doing that long time ago, and I am ok with it.. You should be current - if your not, then yeah any issues that come up are outside the scope of normal support.

Now there might be some talking points about 2.4.5p1 - since this is still listed as supported.

https://docs.netgate.com/pfsense/en/latest/releases/versions.html

But yeah anything before that - its up to you to support.

breakaway

Noted. 2.4.4 was so long ago. Time files.

johnpoz

To be honest not a huge fan of acme in general I like the free ssl and all, but the 90 day thing I think is too short overall - and the whole ca change just turns into a whole issue. Good thing your not a TV owner with apps and stuff - where the TV has not been updated, etc.

Only way to fix that is get a new TV, or use a stick for stuff - because the TV makers hate updating shit, they think you should just buy a new TV next year ;)

At least here there is a way to fix it - even if takes a bit of manual intervention.. Good luck doing that with your TV that could of cost your $$

Not sure I am fan of no specific instructions from pfsense - that would be a nice thing to post up, etc. But not like they didn't post a warning that the CA was expiring..

Gertjan

@johnpoz said in Question about the BOGON table:

and the whole ca change just turns into a whole issue

I make up the numbers, but :
Nearly everything these days is TLS based.
Our end-user certificates are short lived - as the TTL of our host names ^^. The common trusted root certificates - there aren't that many after all - will 'expire'. They often last for 3 to 5 years, so a couple of them each month will fade away, and new ones are introduced.

The bottom line is : we want to (have to !) use TLS, we want it to be 'not expensive'.
The ancient rule applies : we got to learn and maintain just another thing.

And yes, on the "what happens if you don't maintain pfSense on the (close to) latest version", I never thought about this one.

@johnpoz said in Question about the BOGON table:

To be honest not a huge fan of acme in general I like the free ssl and all, but the 90 day thing I think is too short overall

Replacing certs, back in the past, when I was using classic annually $ certs and StartTLS certs, wasn't an easy admin task. Welll ... not difficult, but user errors were not (like NOT) allowed. You had to know what you were doing.
The web server was using them, the mail server uses them. DNSSEC was involved, and some others.
Because it was a yearly (two yearly ?) task, most software upgrade and instruction about how to do so could have been changed. So, as humans - me included - are involved in this task, it was messy.
The 90 days or, what the heck : why not one one week - made it necessary to automate it. An that was an important step. It's just good as now I'm not ready to forget how it works *, and I don't have to do it manually any more, greatly narrowing down the chance of f@&ing up.

Letenscrypt works for fine for me for the last couple of years, every month several certs are auto renewed just fine. A simple mail notification informs me that all is well, and after another 15 days, if some cert is not renewing (often because the admin again f*@&ed up).

It's all one big family : to know what "https" is, you have to know what certs are, so you have to know what DNS is, etc. Basically, you have to know what Internet is so you can use it, that's the way I see it. That is, if you want to throw in pfSense in this mix.

@johnpoz said in Question about the BOGON table:

90 day thing I think

I was thinking the same thing back then. It some how vanished. Dono why ;)

** because it's automated, you have to know how it works IMHO.