[Solved] After upgrade to 19.7 routing over IPsec tunnels seems broken

Started by rainerle, July 23, 2019, 05:07:10 PM

Previous topic - Next topic
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?


Same problem here. IPSec tunnel won't work.

Is downgrading the solution, really?


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

Quote from: rainerle on July 26, 2019, 03:06:54 PM
(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.

Quote from: Zenspartan on July 31, 2019, 10:07:36 PM
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


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...

Quote from: rainerle on September 03, 2019, 12:50:16 AM
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