Messages

Bugreport erstellt: https://github.com/opnsense/core/issues/3789

Ja, auf Intel-CPUs läuft das bei mir auch problemlos.
Im Eventlog steht die Meldung TLB page size mismatch. Ich habe eine neue VM mit dem aktuellsten Image installiert.

Leider keine Ideen, aber das selbe Problem :(
Windows Server 2016, AMD Phenom II

Bist du irgendwie weitergekommen? Ich habe es nach drei Versuchen geschafft, OPNsense zu installieren, aber stabiler Betrieb ist nicht.

No, the Hoster does the VXLAN stuff. For OPNsense it's just plain VLAN (and not even that, because I tag the VLAN on the hypervisor side ;))

I solved this with separate subnets for each server. Seems like OPNsense indeed got confused because the packets had the "wrong" IP address for the interface.

Okay, the connection seems to work now - stupid local firewall got activated somehow on SRV2.

But still, why the weird log message?

I have two servers connected with a slow, but secure tinc bridge and a fast, but unencrypted VXLAN link.
Both servers have a OPNsense VM running.
I want to send specific traffic over the VXLAN and everything else over the tinc link. Because of stupid software design I cannot use separate IP addresses for this (that would be easy), I have to change routing depending on the packet.

Code Select Expand

[SRV1] 10.8.0.1 --- 10.8.0.241 [OPN1] 172.16.4.1 --- VXLAN --- 172.16.4.2 [OPN2] 10.8.0.242 --- 10.8.0.2 [SRV2]
    \                                                                                                       /
     ------------------------------------------- tinc bridged to LAN ---------------------------------------

I have created a firewall rule on the LAN telling OPNsense to use the 172.16.4.2 as gateway for packets with a destination port 444.
This works. Packets appear on the OPN2 VXLAN interface with correct source and port. But the connection does not work.

What's weird is that OPN2 shows this in the firewall log:
nterface   Time   Source   Destination   Proto   Label   
LAN   Jul 9 12:39:05   10.8.0.1:64796   10.8.0.2:444   tcp   let out anything from firewall host itself   
VLAN   Jul 9 12:39:05   10.8.0.1:64796   10.8.0.2:444   tcp   USER_RULE

Why from the firewall host itself? It's clearly from another machine. Does OPNsense / pf get confused because the packets arrive at the "wrong" interface?
There are no drop log entries anywhere...

+1
I'm having the exact same problem.
HTTPS, SMTPS (TCP/465) and IMAPS (TCP/993) can be handled by HAProxy, but for explicit TLS with STARTTLS the cert needs to be on the Exchange box(es).
At the moment I export the certs manually every 60 days, which is manageable but annoying. I have a PRTG sensor to check the certificate and reminds me if I forget.

Ideal would be some kind of trigger that exports the certs via SMB or SSH to another server after every LetsEncrypt refresh.

Alternatively HAProxy could learn to handle STARTTLS, but I guess that's far more effort.

Use OpenVPN instead. Yes, I'm serious.

Fehler ist behoben, siehe Github. Entweder den Patch installieren oder einmal von HTTP auf TCP und wieder zurück stellen, dann taucht die Checkbox wieder auf.

Huch, ist mir gar nicht aufgefallen, dass die Option weg ist  :'(
Ich hab mal ein Ticket aufgemacht:
https://github.com/opnsense/plugins/issues/647

I don't see why MSSQL connections (TCP/1433) should even go through the web proxy.

Huh. Clutching at straws here - do you even NAT the MSSQL box? Are there so many SQL connections happening that the OPNsense state table runs full?

Could you describe the networks and firewall rules pertaining to the MSSQL connections?

Do the MSSQL connections go through the OPNsense box?
Is there extensive firewall logging or something like that?
What does the OPNsense CPU load look like?
What hardware does OPNsense run on?
Do the timeouts also occur if you run the SQL queries directly on the MSSQL box?

Warte damit auf die 18.1 Ende des Monats, die hat einen Mailproxy als Plugin.