Messages

It's related to alias

From my perspective, this looks like a bug in 26.7, because it should not happen, that the firewall has a different behavior after clicking "Apply" and after a reboot.
After reboot, the behavior is the same like in 26.1, but not after "Apply".

So we have to stay at 26.1 as long this is not fixed.


Thanks a lot

Ivo

Floating rules are processed before interface rules, it's expected behaviour: https://docs.opnsense.org/manual/firewall.html#processing-order

Yes, but the first (blocking) rule has "Quick: false" and it should not be handled different after a reboot and at 26.1.

They didn't change with 26.7, but it's different between legacy and "new" rules.

On this firewall, we never used the legacy role dialog, from scratch we used the "new" rules and I can imagine, this is maybe the problem.


Ivo

Hi

After we updated to 26.7 we struggling with floating rules.

So for example, we have a rule where allowing remote networks via IPSec to internal networks as interface rule and another role where deny all traffic to other subnets as floating:

Floating rule:
Interface: nothing selected
Quick: false
Action: Block
Protocol: *
Source: *
Port: *
Destination: alias_all_int (as subnet alias 10.16.0.0/20)
Port: *

Interface rule:
Interface: IPsec encapsulation
Quick: true
Action: Pass
Protocol: *
Source: alias_net_ipsec_dest3 (as subnet alias 172.27.9.0/24 192.168.2.0/24 192.168.42.0/24)
Port: *
Destination: *
Port: *

• Before upgrade it went fine
• After upgrade, the first rule (floating) matches and blocks all traffic
• After disabling, an automatic generated (default blocking) rule blocks the traffic, so enabling again...
• I removed the "IPsec encapsulation" from the interface list, so it moves up to the floating rules, i moved it before the blocking rule -> still blocking the IPsec traffic
• Rebooting the FW -> now, the right rule is taken and the traffic is accepted
• Moving rule back as interface rule ("IPsec encapsulation"), still running fine
• FW reboot -> The blocking rule wins and the traffic is blocked again
• Snapshot restore to 26.1.11 -> Everything is working again

So I think, there is something where goes wrong in 26.7. Maybe interesting: We started with this FW with 26.1 and worked from beginning on with "Firewall > Rules [new]", nothing was edited or added in "Firewall > Rules"...

Ivo

NAT is the only way to do this if it works at all with OPNsense

Sure, this is possible as I wrote, but no NAT thorough the remote side, the NAT should be on the LAN2 interface.

I tried to give constructive infos and recommendations though.

Again: Natting on your site is no option to solve this.

Yes, that's true, thank you.

It's a bit frustrated to get such replays where are not that constructive. I wouldn't post and invest a lot of try and error time if the solution is that easy like to change the subnet.

This has a reason why I can't change the numbering and sometimes it's just a fact.

Thanks a lot

Ivo

:-) Hehe, would be nice if I can do that.

This is only the little top of the the whole network. Many routes, many tunnels at all the gateways, crossing the whole Europe...

Hi

I have the problem, that we have two subnet with destination 192.168.2.0/24, one is direct connected to OPNsense (26.01), the other via IPSec:

LAN1: 10.16.5.254/24
LAN2: 192.168.2.3/24
IPSec destination: 192.168.2.0/24

The hosts in the LAN2 subnets should see the hosts from LAN1 with the GW IP 192.168.2.3, reachable from 10.16.5.0 subnet with 192.168.22.0 and no communication back to 10.16.5.0, so only one-way.

The hosts on remote subnet via IPSec must be reachable from LAN1, but not from LAN2 with 192.168.2.0 addresses, also from the remote 192.168.2.0 subnet, the 10.16.5.0 hosts must be reachable.

I try 1:1 NAT, Outgoing NAT, Destination NAT and some combinations of then, Filter roles with and without gateways, no luck. At the most of the configurations, the traffic goes via IPSec, but not to LAN2 or was not NATed.

Any hints are welcome.

Thanks a lot
Ivo

Hi

We struggling with the similar problems. All new exported client configs doesn't work:

Code Select Expand

Options error: Unrecognized option or missing or extra parameter(s) in xxxx_xx01_fw01_openvpn01__Superadmins__xxx.ovpn:4: data-ciphers-fallback (2.4.7)
Use --help for more information.


I tried on our client:
OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 22 2022

And I also can't find an option for "data-ciphers-fallback" in (but I can't try with the ovpn file at the moment)
OpenVPN 2.6.1 [git:v2.6.1/2c2a98a0e559928c] Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Mar  8 2023

The old exported configurations works fine and also, after we remove the "data-ciphers-fallback" line in the client exported .ovpn file or with the workaround from chrishh

It's a bit strange, because it should be work since 2.3: https://community.openvpn.net/openvpn/wiki/CipherNegotiation

gruss ivo

Salü Franco

For sure we only use opnSense :-)

Without the patch in the main office, we had different versions in place; between 19.1.2 and 19.1.4 and we can't connect to any side.

Maybe this is interesting: We patch only the FW on the main office (19.1.4 + patch) and it runs fine with the unpatched 19.1.4 boxes and 19.1.2 to .3 from the branch offices.

gruss ivo

Hallo zusammen

Die verwendete Hardware wäre doch noch interessant und hat mal jemand die MTU kontrolliert?

Wir betreiben eine opnSense auf einem Intel Server mit XEON in einem Datacenter mit 10GB Fiber und haben keine schlechteren Ergebnisse als mit unserer grossen Cisco ASA im gleichen Datacenter und gleicher Leitung.

gruss ivo

Salü gs

Why you trace to 10.10.12.3 and not to 10.10.12.2?
What about 10.10.12.1, where you define it?

gruss ivo

Salü Franco

It looks fine after applying the patch:

- Update 19.1.2 --> 19.1.4
- Manual Reboot
- Applying patch
- Manual Reboot

Besten Dank und schönen Abend.

gruss ivo

In the console:

opnsense-revert -r 19.1.2 opnsense