To 2.5.0 or not ? that is the question :)
-
I have updated to 2.5.0 and relayd is broken.
So if you rely on this wait a little bit with the update.
-
I also noted on searching for the relayd problem that on the cli the file clog is missing. So now comes the fun part. Which command to read the relayd.log which is binary.
-
Postitive post :)
I have 2 units running HA with pfBlockerNG latest Devel version, OpenVPN for remote access and the OpenVPN client export package, 18 IPsec site to site tunnels, several VLANS, and manual outbound NAT for different VLANS going out on different IP addresses. I run the DNS resolver with domain overrides for customers AD access.
The hardware is a PC Engines APU2d4 with 4Gb Ram, AMD GX-412TC CPU
Upgrade was done using the Web GUI interface from latest 2.4.5. I went for the master first so took backup of config, put CARP into Persistent Maintenance Mode, no one shouted so assumed the rest of the house still had internet then went for the upgrade.
All went through with no issues. Ran a few tests and checked that the config all looked good and exited the Maintenance Mode. Again no shouting from the household so all good.
Then went on and upgrade salve again with no issues.
The routers have now been up for 1 day, 13 hours with no issues.Now, I have found one issue but it's only a display issue. On the Dashboard I have the IPsec status Widget
The Active / Inactive are back to front. I currently have 1 inactive tunnel and 17 active.
If thats the only issue then I'm happy :)
-
Positive upgrade.
Starting from 2.4.5p1, 5 VLANs, 5 VPNs site-to-site (2 IPSec and 3 OpenVPN), 1 OpenVPN road-warrior, pfBlockerNG-devel.
Setup new device from scratch with 2.5.0/zfs, imported old (2.4.5p1) full backup. Added by hand Realtek drivers as pointed before. Lastly, migrated road-warrior VPN from OpenVPN to WireGuard (1 tunnel, n peers.
Possible issue if more than 1 tunnel is actively used).System up and running.
-
To anyone having OpenVPN issues, double check your cryptographic parameters in client and server. I had to add ncp-disable to my PIA connections to get them working again. Also, the update broke my site-to-site connection and I discovered that the IPv4 tunnel network on the client side was blank and was somehow previously working with it blank and with a certificate that didn't exist on the server.
-
@thesurf There is no relayd in 2.5 and it's unlikely to ever come back. It's in the release notes:
https://docs.netgate.com/pfsense/en/latest/releases/2-5-0.html#security-errataYou should use HAProxy instead if you need that functionality.
Steve
-
@seamonkey said in To 2.5.0 or not ? that is the question :):
discovered that the IPv4 tunnel network on the client side was blank and was somehow previously working with it blank and with a certificate that didn't exist on the server.
Something like this could be issues for many users problems. Something that was allowing something to work that was in fact a bug or problem.
As another example - not actually related to 2.5.. But is a sim sort of example. I had freerad running and auth phones to my wireless via eap-tls. There was an update to the freerad package that broke my setup. Because I didn't actually have any uses setup, but it was authing anyway just on cert and not actually checking the cn on the cert matching to username.. When the package was updated to fix that, it broke my connection.
So its quite possible some changes in stuff could break specific setups that were working - but really shouldn't have been..
-
There was a whole bunch pointless and abusive arguing in this thread that I have removed.
Please keep it civil.
Everyone here is working to resolve whatever issues there may be in 2.5. Actual reports with data to allow us to replicate are what will achieve that.
Thanks,
Steve -
@johnpoz In other words, the pfSense update doesn't suck. pfSense just got better at letting you know when your configuration sucks.
-
^ yeah that could be the case in some.. Not saying all, but sure some.. This is why details are so important when reporting something doesn't work. When working through my problem - the thread around if you want to look... It took a bit of time to track it down. Viktor was most helpful in finding the issue..
And after finding it - it was a d'oh moment for sure. Was like how and the hell was it working for so long before ;)
-
Currently the GUI renders a invalid frr config when bgp as-path ACLs are in use. This ACLs will be written under the "router bgp <asn>" section what causes FRR and bgpd daemon failing to start. Switching to raw config mode and putting all bgp as-path access-list outsite the router bgp section is the only way to work this around. Prefix-lists and route-maps are not affected by this and will be written correctly to the config.
Another difference is that bgpd starting with Version 7.5 does default filtering for route announcements . Without a outbound route-map in the neighbor statement, no routes will be announced at all. An empty "route-map permit <seq>" does the the job.
From the release notes of frr7.5
I suggest to put this kind of Information into the Release Notes of pfsense 2.5.0 as well, so customer can prepare configuration before updating.
The next difference compared to 2.4.5 is, that now IGP route synchronization is in effect. I could not disable it by using "no synchronization" in der bgpd config. So when you configure prefixes by the network statement, that are not in the routing table, it's necessary to configure a static route to Null for that networks on the device. This is pretty common on many network devices, but not was not necessary in 2.4.5.
One of my peers teared down after some time and wasn't able to get into Establish state again at all. Had to reboot to resolve this. Logs said something like "Couldn't write to socket: Permission denied," (Can't recall the exact message and haven't saved the Logs before rollback). The other two BGP Session stayed up for about two hours.
Thats what I figured out for bgp on 2.5.0, hadn't have the chance to look into ospf yet.
It's not directly releated to frr but I also noticed that IPsec VTIs stays at MTU of 1400, regardless whats configured on the Interface.
route -n get <ip> route to: <ip> destination: <ip> fib: 0 interface: ipsec1000 flags: <UP,HOST,DONE,PINNED> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1400 1 0My favorite Bug affects 2.4.5. Since I want to stay on 2.4.5 for now, I decided to change the Branch back to Previous stable version. Doing so uninstalls frr completely - no questions asked.
-
Upgraded to 2.5.0 about 10 hours ago from the GUI. The update went smoothly and took a total of less than 15 minutes. I was able to login to the GUI after the upgrade was completed. Everything has been running well and has been stable. I had 2 issues that came up post upgrade.
Issue 1: I had 3 openvpn connections that were down. Before the upgrade I had read some posts where others had had the same issue. The fix was to uncheck the "Data Encryption Negotiation" setting in the openvpn client setups. As soon as the setting was unchecked and saved the connections were immediately reinstated.
Issue 2: Once pfBlockerNG-devel was reinstalled the DNSBL was out of sync. It was easily resolved with a Forced/Reload in the Update tab in pfBlockerNG.
My setup includes the following: 1 WAN, 2 regular interfaces, 4 vlans, multiple DHCP Servers, DNS Resolver, Dynamic DNS, 3 openvpn clients, 2 openvpn servers.
-
@artes said in To 2.5.0 or not ? that is the question :):
/usr/local/etc/rc.d/frr restart all Checking intergrated config... Checking vtysh.conf line 37: % Unknown command[4]: address-family ipv4 unicast line 38: % Unknown command[4]: network <ip>.64.0/20 line 39: % Unknown command[4]: neighbor <ip>.16.1 activate line 40: % Unknown command[4]: neighbor <ip>.16.17 activate line 41: % Unknown command[4]: neighbor <ip>.16.29 activate line 42: % Unknown command[4]: neighbor <ip>.16.1 send-community both line 43: % Unknown command[4]: neighbor <ip>.16.1 next-hop-self line 44: % Unknown command[4]: neighbor <ip>.16.1 soft-reconfiguration inbound line 45: % Unknown command[4]: neighbor <ip>.16.1 route-map Site_Kref_Primary_RMAP in line 46: % Unknown command[4]: neighbor <ip>.16.1 addpath-tx-bestpath-per-AS line 47: % Unknown command[4]: neighbor <ip>.16.17 send-community both line 48: % Unknown command[4]: neighbor <ip>.16.17 next-hop-self line 49: % Unknown command[4]: neighbor <ip>.16.17 route-map HDC-LOCAL-PREF80 in line 50: % Unknown command[4]: neighbor <ip>.16.29 send-community both line 51: % Unknown command[4]: neighbor <ip>.16.29 next-hop-self line 52: % Unknown command[4]: neighbor <ip>.16.29 route-map HDC-LOCAL-PREF90 in line 53: % Unknown command[4]: exit-address-family FAILEDIf somebody is using FRR for BGP be carefull - Zebra and BGPd won't come up and your network is fried if you rely on it. Thanks to virtualization and snapshot it's possible to minimize damage.
yes, i am using frr and network down.
-
@jwj said in To 2.5.0 or not ? that is the question :):
https://nyifiles.netgate.com/mirror/downloads
Do you have another pointer ?
This one points to 2.5.0 -
@chudak No. The older ones have been removed from the mirrors.
-
i have some old version, maybe i have to change to old version for test.
-
Open a ticket and we can get you a link to 2.4.5p1 if you need it for now: https://go.netgate.com/
Steve
-
@jwj said in To 2.5.0 or not ? that is the question :):
@chudak No. The older ones have been removed from the mirrors.
I learned the hard way ....
Always download & save a copy of the install packages used, along with the SHA256-SUM.
That goes for "even if you do just upgrade" , always get an install image of the version you have upgraded to.I upgraded from 2.4.4-p3 to 2.4.5-p1 , and luckily remembered to get a copy of the 2.4.5-p1 install image , even though i never installed from that image.
Is handy to have right now , if i need to fallbck.
/Bingo
-
@bingo600 said in To 2.5.0 or not ? that is the question :):
@jwj said in To 2.5.0 or not ? that is the question :):
@chudak No. The older ones have been removed from the mirrors.
I learned the hard way ....
Always download & save a copy of the install packages used, along with the SHA256-SUM.
That goes for "even if you do just upgrade" , always get an install image of the version you have upgraded to.I upgraded from 2.4.4-p3 to 2.4.5-p1 , and luckily remembered to get a copy of the 2.4.5-p1 install image , even though i never installed from that image.
Is handy to have right now , if i need to fallbck.
/Bingo
This is a good practice.
More interesting is why Netgate won't allow access to older versions ?! -
Open a ticket and we can get it to you if you need it.
