OPNsense Forum
Archive => 19.7 Legacy Series => Topic started by: rainerle on July 23, 2019, 05:07:10 pm
-
Hi,
just upgraded today.
After applying the following patches
fabaef0a 6b1f3e60 9287b55 64858b5
I still have the problem that routing from devices within the network over a VTI (ipsec1000) does not work.
Ping from opnsense01 does work and the tunnel is up.
Clients on the same location as the opnsense are not able to ping. The traceroute shows the client is trying to connect via the opnsense but then just stars out.
Now I tried to downgrade to 19.1.10
root@opnsense02:~ # opnsense-update -u -r 19.1.10
Fetching packages-19.1.10-OpenSSL-amd64.tar: .. failed, no signature found
root@opnsense02:~ #
How do I properly downgrade a complete release?
-
So I downgraded using
https://github.com/opnsense/update/blob/master/bootstrap/opnsense-bootstrap.sh
and adjusting the variable Release to "19.1".
-
Same problem here. IPSec tunnel won't work.
Is downgrading the solution, really?
-
Only route based affected? Do you use AES auto in Phase2?
-
Try 19.7.1. There seems to b a PHP variable scope bug during boot (only).
Cheers,
Franco
-
Hi,
yes, we are using AES(auto) in Phase 2.
I am back to 19.1.10_1. Had some downtime now from the failed upgrade and the failing takeovers during the downgrade.
During a support session with Ad we probably found the reason for the failing takeovers (using the same vhid group for different VLANs on the same LAGG interfaces). Haven't tried a failover yet... propably scared now...
...and will definitely wait for a few versions of 19.7 now...
Thanks for looking into the routing issue though!
Cheers
Rainer
-
(using the same vhid group for different VLANs on the same LAGG interfaces). Haven't tried a failover yet... propably scared now...
:o
-
So,
did a "controlled" failover using the "Enter Persistent CARP Maintenance Mode" button and a failover by forcing an unexpected reboot (TM). Feeling confident again...
@N3rD: Did 19.7.1 fix your problem?
Thanks
Rainer
-
I have the same problem (I think) Tried to set up routed IPSec tunnel between two sites with 19.7.1 fresh install--set up Phase 1, Phase 2 on each box, Created pass-thru rules, a GW, set up route. As soon as I ran enable, both boxes were inaccessible via web gui (or from LAN side period).
Since it was a fresh setup, I set it up identically using PF-Sense 2,4,4 and it worked fine...I'd rather use OPNSense, but time is running out...
-
Same issue here 6 tunnels, all not routing traffic correctly. Using 19.7.1, the traffic seems to being Nat’d on the given the tunnel interface. No blocks on the firewall.
-
Same issue here 6 tunnels, all not routing traffic correctly. Using 19.7.1, the traffic seems to being Nat’d on the given the tunnel interface. No blocks on the firewall.
Can you open a new thread? It's hard to track different issues in one thread
-
will do
-
So I felt confident enough tonight and upgraded from 19.1.10 to 19.7.3. I upgraded the secondary HA partner first and then clicked "Enter persistent CARP maintenance mode" on the primary.
All services on the WAN interface went down. After being able to log onto that firewall and some fiddeling around the causing error was found: I had to adjust the GeoIP based rules on the WAN interface and convert them to use any instead.
Somehow the GeoIP based rules are not working.
I executed the following scripts before changing to any, but that did not help:
/usr/local/opnsense/scripts/filter/download_geoip.py
/usr/local/etc/rc.filter_synchronize
/usr/local/etc/rc.filter_configure
Can anybody shed some light into this?
Thanks
Rainer
-
...and I am back to the primary HA cluster partner with version 19.1.10_1.
Got the following error on the secondary HA cluster partner this morning...
...
Sep 3 08:56:45 opnsense02 kernel: ixl2: WARNING: queue 2 appears to be hung!
Sep 3 08:57:32 opnsense02 kernel: ixl2: WARNING: queue 6 appears to be hung!
Sep 3 09:10:18 opnsense02 kernel: ixl1: WARNING: queue 6 appears to be hung!
...
And then the services went down since those are the lagg members...
-
So I felt confident enough tonight and upgraded from 19.1.10 to 19.7.3. I upgraded the secondary HA partner first and then clicked "Enter persistent CARP maintenance mode" on the primary.
All services on the WAN interface went down. After being able to log onto that firewall and some fiddeling around the causing error was found: I had to adjust the GeoIP based rules on the WAN interface and convert them to use any instead.
Somehow the GeoIP based rules are not working.
I executed the following scripts before changing to any, but that did not help:
/usr/local/opnsense/scripts/filter/download_geoip.py
/usr/local/etc/rc.filter_synchronize
/usr/local/etc/rc.filter_configure
Can anybody shed some light into this?
Thanks
Rainer
please open new thread
-
...and I am back to the primary HA cluster partner with version 19.1.10_1.
Got the following error on the secondary HA cluster partner this morning...
...
Sep 3 08:56:45 opnsense02 kernel: ixl2: WARNING: queue 2 appears to be hung!
Sep 3 08:57:32 opnsense02 kernel: ixl2: WARNING: queue 6 appears to be hung!
Sep 3 09:10:18 opnsense02 kernel: ixl1: WARNING: queue 6 appears to be hung!
...
And then the services went down since those are the lagg members...
maybe worth open a bug report on GH, perhaps check if you can update the nic firmware too, esp. when you use X710
-
Thanks for the quick replies!
Updated the firmware on the Lenovo ThinkServer Intel X722 LOM board today and it seems the hanging queues messages are gone now.
Will open a separate thread for the GeoIP problem.
Thanks
Rainer
-
Good!