first of all I want to say, that opnsense is a really nice and reliable firewall solution.After having a steep learning curve we now got very reliable results in comparison to pfsense.With pfsense (a nice firewall solution as well) we did many times crash our configuration without any clue, why this happened.With opnsense everything works as it should - besides a nasty problem with our mailserver.

Problem (configuration details see below): Mailserver with fixed IP over OpenVPN-Client-DialIn to an IP-Provider. NAT of ports 25 (SMTP), 143 (IMAP with StartSSL), 587 (Submission with StartSSL). NAT-Outbound rules are set.The mailserver is working well. Mail can be received and sent by SMTP (25) to the outside world.Clients can fetch and send email by IMAP (143)and SMTP (587) from all LAN interfaces.But #1: clients cannot fetch and send email from outside our LAN.But #2: Sometimes it works from outside our LAN...

The problem is: it works - sometimes...Firewall tells us: connection (TCP) establishedBut if we test with telnet from different WAN-line or by LTE we cannot always connect with telnet.Two lines do work, other lines do not work...Our log does not tell us any blocked situation.

Our configuration:OpenVPN-client to IP-Provider (Portunity) to get a fixed IP.WAN-DialIn with Fritzbox-Routers. Opnsense ? exposed host.IP of Routers: 10.3.201.1 | 10.3.202.1 | 10.3.203.1 - mmh, one LAN interface does have the same IP range, but different Mask.... opnsense has fixed IPs according to those IPs: 10.3.201.2 | 10.3.202.2 | 10.3.203.2Mask: 255.255.255.0Could that be part of the problem?

Comment: we put also our external IP (42.8.5.2) as destination address in those rules - no difference. We used TCP/UDP for Ports 587+143 just for testing, whether StartSSL could cause our problem._____________

outgoing:internal IP -> Gateway: Portunity-VPN -> InternetIf we check the outgoing route (tracert), everything seems to work.And more amazing: Port 25 (SMTP) with no SSL seems not to make any troubles at all.All emails can be received and sent...

We also use the NAT outbound rule to get the packets back on the same way.

We did an external port testing - all ports are open.We tried to connect with telnet - no answer.

In the meantime we made a fresh installation on a second place and everything is working out of the box.

Could it be, that SSL-certificates (self-issued) are filtered?We recognized that with another site, that opnsense is filtering mailconnections and give out a "password error", although we did not activate any squid or IDS/IPS filtering.... (we just activated IDS once and deavtivated it for further testing).

It's highly unlikely that this is a SSL filtering issue, traffic is not touched without IPS in place.

In most cases this revolves around rules that drop parts of the traffic, one direction not getting the packets back as expected (no NAT) or routes pointing in the wrong direction locally.

Since you also have OpenVPN this is probably where the biggest problems can arise--where MTU might matter, the protocol type used, tun vs. tap usage, etc. Sorry for not being able to be more specific here. It might help to experiment with these settings.

thanks for your suggestions.We just reinstalled the firewall and stumbled over a problem with one internet line.We will change router and are resetting the line right now. It is a cable internet line (not ADSL/VDSL) and cable carrier are not very reliable in Germany...The problem with this configuration (cable internet + OpenVPN DialIn + fixed IP) is: it worked for years with another software firewall. That does not mean, you cannot run into troubles...

We will keep you informed about our procedures to solve that nasty problem.

Steep learning curve? Mmh, many new settings with every update, compared to pfsense a working framework.Maybe it would have been more correct to write: a steep, but very short learning curve...

Many things just work, as they should. Sometimes it is too simple, to believe, that it just works.But sometimes you wonder, why something simple (like DynDNS updating) does not work out of the box.

If we can pinpoint the problem I see no reason to not have it fixed for at least the same number of years to come.

Thanks for explaining. I think people get used to this weekly thing. Upgrades are fun and easy. There are some ideas about providing a fixed version with bugfixes only, but we're still weighing options.

DynDNS may reveal additional info in the system log file (just filter for e.g. "dns" there) or running the scripts manually from the console. Mostly typos in domains or missing connectivity, sometimes an unmaintained DynDNS provider that needs a bit of work to adapt to a new API or parameter rename.

Grüße,Franco

PS: Although I'm stuck on 50 Mbit ADSL now, I do not ever want to go back to the previous 100 Mbit cable experience...