Question about the BOGON table

breakaway

Earlier today had an issue where a user could not connect to our equipment.

After some digging I traced the fault to the fact that this user's IP is resident in this BOGON range

103.172.32.0/19

My bogon update frequency is set to 1 month. I checked, but it appears the system has not been able to update for a while now. The last update was on

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

I then verified that THREE other pfSense installations (2.5.1 and 2.5.2) also have this range present in their "BOGONS" table.

I also verified all 3 pfSenses can reach files.pfsense.org on port 80 (via the DNS and Port Test diagnostic function)

Finally I did a force an update thinking maybe the table is out of date. However, despite running a force update it still says Table Last Updated on Fri 20 Aug 04:50:01 2021 GMT.

What gives? Whos fault is this? Is the table supplied by netgate/pfsense out of date? I

johnpoz

@breakaway all valid points and great troubleshooting to root of the issue.

Pfsense pulls the update from their own location, so it being current falls to netgate/pfsense

I will flag @stephenw10 to grab some attention.

Bogon is more fluid than ever.. So yeah they should update that pretty much daily, and then pfsense can update their copies monthly.. This way any given install is no more than 30 days old.

There was a recent thread where bogon came into play, and local table was from aug 20.. I didn't dig into it farther back then because is wasn't that long past then. Lets see if Steve chimes in and this gets some attention. If not I will make sure it does.

breakaway

@johnpoz Thanks.

Today, due to an unrelated issue (failed SSD) I had to rebuild my pfsense at home.

I did a force update on the bogons table afterwards, and it says this after the update:

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

Definitely looks like the source is not being updated?

Gertjan

@breakaway

While some one somewhere, upstream, takes care of things, what about editing the file, and remove line 674 - 103.172.32.0/19 ?

johnpoz

@breakaway yeah, the docs say something like once a month.. But Aug 20 is clearly over a month ;)

https://docs.netgate.com/pfsense/en/latest/firewall/rule-methodology.html#firewall-block-bogon-networks
This list does not change frequently, and new IP address assignments are removed from the bogons list months before they are allocated, so a monthly update is adequate.

The source where I believe it is pulled from..
https://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt

Was updated today 10/14... If you compare that with the aug 20 list from pfsense.. There are quite a few differences..

Back a few years there were rarely changes to the bogon list, but as IPv4 was/is used up, more and more that was bogon is being activated..

I will try and reach out to Steve today, since he seems to have not taken notice when I flagged him yesterday. Or didn't comment that he did - he may very well be hard at working getting this looked at by the appropriate team..

edit:
@Gertjan and @breakaway a simpler solution/work around would prob be to just not block bogon.. While sure it is the "right" thing to do - its overall "security" aspect could be debated. If something is truely bogon, and not routing on the public internet. The only place that traffic could come from is the users isp, or udp sort of traffic that expect no answer.. The risk of said traffic to the services you open to the public internet is minimal a best if you ask me.. Your more likely to cause your self work, as seen by by this thread than mitigate any sort of serious security risk.

That being said - the list should still be kept current..

If you are heart set on blocking bogon - you could create an alias that pulls that list from the above link.. And use that bogon list vs the one provided by pfsense in your own firewall rule and turn off the built in bogon filtering. I wouldn't pull it all that often, or you could find yourself banned from pulling it.. And you would be putting load on team-cymru services..

edit2: example of pulling your own bogon list

Keep in mind that the pfsense bogon pulls out some rfc1918, so if your using rfc1918 on your wan and have unchecked not block rfc1918, this bogon table would block rfc1918. Notice the 10/8 being listed in the table.

btw the number of rows being only different by 2 (1368 vs 1370) is a misleading indication of how many differences between the tables.. I compared the 2 lists - and there are quite a few differences..

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.