HE IPv6 tunnel and pfSense Update

AberDino

I've got pfSense v2.6.0 running with a HE IPv6 tunnel and over the last few days I noticed the update check would fail with "unable to check for updates". Pinging pfsense.org would reveal an IPv6 address but no response. I then added ".pfsense.org" to the Python no AAAA List, forcing IPv4 DNS resolution for that domain, and the update check now works properly. This could of course be a transient issue or perhaps it's a conscious decision to block HE IPv6 traffic (as we've seen with other organisations such as Netflix). Anyway, just posting this in case it helps somebody else.

Gertjan

@aberdino

Same thing here.

GUI :

Console option 13 :
..... (no go ) .....

Looking at the documentation, I wind up here :
/usr/local/libexec/pfSense-upgrade
The first several lines explain the command options (open it, it's just readable plain English text )
So I tried the first : I force IPv4 : and yes :

[2.6.0-RELEASE][admin@pfsense.atwork.net]/etc: /usr/local/libexec/pfSense-upgrade -4
>>> Updating repositories metadata...
Updating pfSense-core repository catalogue...
Fetching meta.conf: . done
Fetching packagesite.pkg: . done
Processing entries: . done
pfSense-core repository update completed. 7 packages processed.
Updating pfSense repository catalogue...
Fetching meta.conf: . done
Fetching packagesite.pkg: .......... done
Processing entries: .......... done
pfSense repository update completed. 511 packages processed.
All repositories are up to date.
Your packages are up to date

When I try IPv6 :

[2.6.0-RELEASE][admin@pfsense.atwork.net]/etc: /usr/local/libexec/pfSense-upgrade -6
>>> Updating repositories metadata...
Updating pfSense-core repository catalogue...
....
( I'm still waiting, no reply)

I guess the IPv6 peering has a problem. It could be ipv6.he.net.

Btw : I'm posting on the forum only using IPv6. I know the forum web server has nothing to do with the "package and updates" Netgate server.
IPv4 works fine, so, if needed, Ill force the IPv4 usage (see line 1415 : unset the unset)

edit ; why would you ping pfsense.org ? Why not netgate.com ? And even if ping6 works, what would that tell me ?

AberDino

@gertjan said in HE IPv6 tunnel and pfSense Update:

edit ; why would you ping pfsense.org ? Why not netgate.com ? And even if ping6 works, what would that tell me ?

I couldn't find which url was used for updating pfSense, so it was purely a guess and a process of elimination. I received a ping/traceroute response for pfsense.org on IPv4 but not on IPv6, so that's when I decided to add .pfsense.org to the "no AAAA" list and see what happens . Since then I've added .netgate.com as well, just in case.

Gertjan

@aberdino said in HE IPv6 tunnel and pfSense Update:

I couldn't find which url was used for updating pfSense

Me neither.
It's a bit complicated. It's a A or AAAA record point to a CNAME pointing to a _serv record that points to the two files01 ~~and files02~~ (.netgate.com) servers.
Something like that.

Anyway : run :

/usr/local/libexec/pfSense-upgrade -4

and

/usr/local/libexec/pfSense-upgrade -6

and you see what works, and what doesn't.

johnpoz

@aberdino @Gertjan

I use a HE tunnel - working here

22.01-RELEASE][admin@sg4860.local.lan]/: /usr/local/libexec/pfSense-upgrade -6
>>> Updating repositories metadata... 
Updating pfSense-core repository catalogue...
Fetching meta.conf: . done
Fetching packagesite.pkg: . done
Processing entries: .. done
pfSense-core repository update completed. 14 packages processed.
Updating pfSense repository catalogue...
Fetching meta.conf: . done
Fetching packagesite.pkg: .......... done
Processing entries: .......... done
pfSense repository update completed. 535 packages processed.
All repositories are up to date.
Your packages are up to date
[22.01-RELEASE][admin@sg4860.local.lan]/:

Sure wasn't related to the other issue they were having with some cert and looking for packages or updates were not working?

https://forum.netgate.com/topic/171035/since-about-1400-hours-i-have-been-unable-to-get-updates-in-dashboard

Gertjan

@johnpoz
Thanks for the confirmation.
Must be he.net somewhere.

I could do a IPv4 https request against the pfsense package web server :

fetch -vv -4 -T 300 "https://files01.netgate.com/pfSense_v2_6_0_amd64-core/All/pfSense-base-2.6.0.pkg"

and it downloaded.

fetch -vv -6 -T 300 "https://files01.netgate.com/pfSense_v2_6_0_amd64-core/All/pfSense-base-2.6.0.pkg"

also works fine, and is using, I presume, IPv6.

maybe "/usr/local/libexec/pfSense-upgrade" uses some other URL, as the fetch is just a curl with another name, using a web browser request.

"/usr/local/libexec/pfSense-upgrade" is, as I seem to recall, not using https but something else.

edit :

I waited long enough, it comes back with :

pkg-static: https://pkg01-atx.netgate.com/pfSense_v2_6_0_amd64-core/meta.txz: Operation timed out
repository pfSense-core has no meta file, using default settings

( /usr/local/libexec/pfSense-upgrade -6 in the console . SSH )

and more :

For what it's worth :
[2.6.0-RELEASE][admin@pfsense.atwork-but-not-going-much.net]/root: host pkg01-atx.netgate.com
pkg01-atx.netgate.com has address 208.123.73.209
pkg01-atx.netgate.com has IPv6 address 2610:160:11:18::209

208.123.73.209 replies to ping.
2610:160:11:18::209 no ping6.

johnpoz

@gertjan could be a peering issue somewhere, I prob not using the same pop for HE as you... since we are in different regions ;) I doubt you would be using the Chicago pop for HE, unless you had some want for added latency for no reason - heeheh

edit:
Oh I am not even using the chicago pop, I switched over to Kansas City pop because I was seeing packet loss to the chicago pop for extended period.. Latency difference was only a couple of ms..

Gertjan

@johnpoz said in HE IPv6 tunnel and pfSense Update:

the same pop for HE as you

Paris for me.
https://www.tunnelbroker.net/status.php says ok.
They always say it's ok.
But hey, for a free service, is is always ok by default.

AberDino

Thanks @johnpoz and @Gertjan, very informative

Gertjan

@aberdino

Some changes

[2.6.0-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: php -q pkg_check.php
pfSense version 2.6.0 (installed) is current
pfBlockerNG-devel: 3.1.0_1 ==> 3.1.0_2

So there is a new pfBlockerNG-devel version.

The System > Package Manager > Available Packages populated again.

And now for some humour :

The System > Package Manager> Installed Packages page :

The image is to big for the forum - so I self hosted it here

So pfSense says to me : You have installed ALL the available packages ....

?? Mammmmmmaaaaaaam !!! pfSense thinks I'm nuts.

I should stop messing around.

Upgrading to pfBlockerng-devel 3.1.0_2 worked ... slowly, a couple of minutes for a 2Mbytes file.

johnpoz

@gertjan said in HE IPv6 tunnel and pfSense Update:

Upgrading to pfBlockerng-devel 3.1.0_2 worked

hmmm - not seeing that available, only 3.1.0_1

Gertjan

@johnpoz

That's part of the mess I made : the "what packages are there" info is cached.
At home, I have to wait, like you, for the local cache file times out,n it will get retrieved, and you will see the new version.

I just came home, VPNned into pfsen@work, and grabbed this :

that's what I have at work.
I has Ctrl copied the version from the installer GUI log, but you had me doubting for a moment ...

nowa-it

got the same witout he ipv6-Tunnel. I think it is a pfsense bug.

https://forum.netgate.com/topic/171069/pfsense-2-6-lost-ipv6-connection-on-trackinterfaces-after-two-gateway-reconnects?_=1648183003496

Gertjan

@nowa-it

Maybe I have a dual WAN interface setup, as their is one for IPv4 and one for IPv6 but I'm not 'tracking', as the set up is static for the IPv6.

When I got home yesterday, I managed to install the proposed pfBlocker update over he.net/IPv6. It went slowly ....... like 9600 bits / sec slow.

After my daily Youtube-brain-food, and some data center checking around me ( Europe Internet backbone ) I saw huge traffic going east. Berlin, Warschau and further.
Something going on in east Europe ?? ;)
As he.net is a major player for most transatlantic connections, I guess I just have to wait it out.

edit : found No packages available on multiple CE 2.6 devices - and it looks like it not the ipv6 tunnel from he.net, but more closer to where the update servers live.
Could still be he.net of course.