@Jozy good luck with that mess.. I asked if you had messed with your outbound nat, I didn't say set it to manual..

Auto is the default - all of this would work with clicky, clicky with pfsense out of the box - the only reason it wouldn't is you messed with the defaults, etc..

Or you not even using pfsense as the gateway.. Which it seems your not.. ugggh..

@jarlel said in FreeRadius: Something reduces the value in octet file (used):

Has anybody seen the same? Is there a workaround? Can 64 bit be supported by doing some modifications?

Also make sure you have Authentication setup correctly. In order to update used-octets, CP must be "re-logged in", i.e. reauthenticated so the data is sent from CP to/from freeRadius.

0c0de4a8-2fa1-4241-9405-5c4aee67af65-image.png

@stephenw10 said in I from 24.0.3 upgrade to 24.11 FRR BGP service can't start:

How is it configured? Does it appear correctly in vtysh 'show run'?

no.

show run
Building configuration...

Current configuration:
!
Warning: connecting to mgmtd...success!
Warning: connecting to zebra...success!
Warning: connecting to bgpd...failed!
Warning: connecting to watchfrr...success!
Warning: connecting to bgpd...failed!
Warning: connecting to staticd...success!
Warning: connecting to bgpd...failed!
Warning: connecting to bgpd...failed!
Warning: connecting to bgpd...failed!
frr version 9.1.2
frr defaults traditional
hostname pf
log syslog
service integrated-vtysh-config
!
password
!
ipv6 prefix-list cymru-out-v6 seq 50 deny ::/0 le 128
ipv6 prefix-list ipv6in seq 95 deny fe80::/10 le 128
ipv6 prefix-list ipv6in seq 120 deny 3ffe::/16 le 128
ipv6 prefix-list ipv6in seq 125 deny 2001:db8::/32 le 128
ipv6 prefix-list ipv6in seq 130 deny 2001::/32
ipv6 prefix-list ipv6in seq 135 deny 2001::/32 le 128
ipv6 prefix-list ipv6in seq 140 permit 2002::/16
ipv6 prefix-list ipv6in seq 145 deny 2002::/16 le 128
ipv6 prefix-list ipv6in seq 155 deny fe00::/9 le 128
ipv6 prefix-list ipv6in seq 160 deny ff00::/8 le 128
ipv6 prefix-list ipv6in seq 205 permit 2000::/3 le 48
ipv6 prefix-list ipv6in seq 900 deny ::/0 le 128
ipv6 prefix-list ipv6in seq 999 deny any
ipv6 prefix-list myv6out description my ipv6 out
ipv6 prefix-list myv6out seq 50 permit
ipv6 prefix-list myv6out seq 55 permit
ipv6 prefix-list myv6out seq 60 permit
ipv6 prefix-list myv6out seq 65 permit
ipv6 prefix-list myv6out seq 75 permit
ipv6 prefix-list myv6out seq 80 permit
ipv6 prefix-list myv6out seq 85 permit
ipv6 prefix-list myv6out seq 999 deny any
!
route-map RPKI deny 20
exit
!
route-map RPKI permit 30
set metric 100
exit
!
route-map RPKI permit 50
set metric 0
exit
!
route-map ipv6routein permit 80
match ipv6 address prefix-list ipv6in
exit
!
end

My reboot issue on 24.11 has NOT been resolved!

So 24.11 is unusable to me :(

Netgat TAC support guys suggested it's an h/w issue and offered to wipe out my drive and try to install it clean. I tried uninstalling a bunch of packaging and it did not help.

I am hesitant to wipe out my drive as I will lose my boot env snapshots.

Just posting here for posterity.

@NOCling IIRC but make-before-break is only needed if you are doing re-auth rather than rekeying.

Also not sure how big a difference async makes, I have VPNs that move gigabit without that set, but I do have dedicated CPIC cards for acceleration so maybe it'd make more of a difference on normal hardware. Either way async can break things.

Agreed about the 1328 MSS, though not all TCP workloads support clamping. I have a setup where clamping isn't supported so traffic is fragmented no matter what (in fact 100% of packets are fragmented and I still can manage gigabit lol).

And yeah @hescominsoon like @NOCling says, SMB really isn't ideal for this, if you actually need to move data super fast over a VPN, you should look elsewhere. Even NFS should be better.

@FrostElara Activate the TLD in pfblockerng and add it to the blocklist. pubgmobile.com I solved it by adding the address. Of course, it works by blocking external DNSs.

@Antibiotic said in Squid error "FATAL: Unknown http_port option 'NO_TLSv1":

$sslproxy_options . = ",NO_TLSv1";

Did you manage to get this working? I just put a new SSD and re-installed and squid is now broken for me - looks like the same error

Hallo zusammen,

aktuell habe ich Probleme mit dem pfBlocker.

Wenn der Internetanschluss von der Telekom nach einem Ausfall wieder da ist, funktioniert der Internetzugang nicht mehr.

Auf dem Dashboard sieht es beim pfBlocker so aus:
pfblocker-4.jpg
Auch ein Update bzw. Reload ändert nichts am Internetzugang.

Das Problem ist auch ab und zu eingetreten obwohl der Anschluss nicht unterbrochen wurde.
Da kann ich aber kein Muster entdecken.

Wird pfBlocker deaktiviert ist sofort wieder alles da.

Was könnte hier der Fehler sein?

Gruß
Alexander

@Gertjan So I used both tcpdump and radsniff to look at packet traces, but I can't see any issues. In both cases (working and non-working) the radius server sends back an Access-Accept message with the same set of fields.

@CreationGuy
What did you try?
How did you access the server? From inside your network or from outside? Which URL?
What exactly did you get?

@marcosm status_output.tgz uploaded to the same link provided above.

Since the previous messages I have installed and configured the Service Watchdog plugin

Hello,

I was able to configure the WAN correctly by defining a VLAN with the tag required by the ISP and define the WAN on this interface.

A step-by-step guide with screenshot is available here: https://ic.rcasys.com/s/RantzDKFxHjX3Ba

Thanks @stephenw10 and @keyser for your support!

@s0ulf3re So what you are showing are the Proxmox interfaces you have set up, right?
vmbr0 with 192.168.1.234 is your Proxmox interface, isn't it??

If you only have one port on Proxmox, I'm thinking you need to use VLANs to be able to separate pfsense LAN away from your main LAN. Otherwise you will have a DHCP and subnet conflict.

Perhaps if you can show your pfsense HW setup in Proxmox?
You have to attach vmbr0 first (as this will be WAN) and then vmbr2. For vmbr2 you add a VLAN tag in Proxmox, and then all your VM's need to have the same ID on their interfaces. Also assuming you have a VLAN capable switch attached where the same VLAN tag i TAGGED on the port.

@NOCling said in Gibt es bzgl. PFSense irgendwelche Besonderheiten zu beachten bei einem WLAN Call von iPhone zu Telekom Mobile?:

Dafür richtest du doch einfach mal sauber das Monitoring in der pf für das WAN GW ein.

Dann kannst du sehen ob an dem Zeitpunkt ggf. das WAN mal ein wenig lost hatte.

Und es gibt auch nur eine WAN Verbindung?
Sonst muss dich gleich um die Stickyness kümmern.

Das die Clients Netzhopping machen kannst auch ausschließen? Sprich auf bestimmten APs im falschen VLAN oder gar keinem landen?

Weil States sind jetzt swid 24.03 Int bound und nicht mehr Floating based.

Das hab ich glaube ich, muss nochmal nachsehen. Ich glaube ich hatte es mal
bei einem anderen Kunden rausgenommen, da in einer FW-Version oder am
Anschluss ein Problem war und da hatte zumindest der automatische Refresh
zu noch mehr Problemen geführt.

Ja, nur ein WAN in diesem Fall.

Nun, hopping der Clients vielleicht nicht zu absolut 100%. Aber es gibt auf allen
APs die für die Clients relevante SSID, in diversen Tests habe ich auch wunderbar
gesehen, dass die Clients von AP zu AP innerhalb des richtigen VLAN springen.
Ich sehe die Clients auch immer im richtigen VLAN, also bis auf dass es u.U.
vielleicht wirklich mal zu einem ganz seltenen Fall kurzzeitig passiert, kann ich
es ausschließen.

Wenn sie in keinem landen würden, dann würde ja auch Internet nicht mehr
funktionieren. Bisher habe ich aber immer die Meldungen gehabt, dass WhatsApp
oder E-Mails dann immer noch funktioniert hat. Nur SMS und der WLAN Call
wurde mir als Problem gemeldet. D.h. die Clients müssen noch mit dem WLAN,
dem VLAN und dem Grunde nach mit dem Internet verbunden gewesen sein.

Aktuell ist diese FireWall noch auf 24.03, hier habe ich noch kein Update auf 24.11
gemacht. Bei mir schon, aber ich betreibe aktuellste Firmware eigentlich immer
erstmal einige Wochen/Monate bei mir bevor ich Kundensysteme aktualisiere.

Ich hatte gestern nochmal die FireWall Konfig mit anderen verglichen und hatte
(warum auch immer) tatsächlich noch Unterschiede gefunden:

Advanced > FireWall & NAT > Hardware Checksum Offloading: war hier noch aktiv, ist jetzt aus (wie eigentlich in allen anderen FW) Advanced > FireWall & NAT > Firewall Optimization Options: steht jetzt wieder auf Normal + Erhöhung der UDP timeouts Advanced > FireWall & NAT > IP Do-Not-Fragment compatibility: war an, ist jetzt mal aus
Ich habe hier aktuell auch die erwähnten VPN Einstellungen hierzu nicht gesetzt, ggfls. teste ich die dann noch.

Mal sehen ob damit in den nächsten Tagen/Wochen eine Änderung feststellbar ist.

I am so sorry to have wasted your time but I've solved this, and it was complete and absolute muppetry on my behalf.

I had, many months ago, attempted to set this same thing up using an IPsec tunnel. The non-working IPsec tunnel was still set up on one of the devices...

Our solution at this point :

Automatically :

Remove unwanted boot environnements Update the train to the stable version Check upgrade availability (pfSense-upgrade -d -c) Prefetch all packages (pkg fetch -u -d -y)

So we want finally launch the upgrade (pfSense-upgrade -4 -d -y) it's faster !