Messages

Actually - self resolved! I had to enable the option in Advanced firewall settings

Bypass firewall rules for traffic on the same interface

Duh :)... must have been enabled on the old instance, so... never mind on that - for those who may get stuck with the same issue, hopefully this helps.

Cheers.

Hi everyone.

Huge fan of the opnsense platform and finally got around to upgrading my opnsense to 20.1.5. I actually installed it from scratch on a brand new disk (running on a physical Dell T420 box).  All went well, configured the interfaces, setup my rules, added static routes to OpenVPN tunnels (handled by another machine on my network), and this is where the fun began.

Now I was running an older release of opnsense prior to today (19.7.10) and did not have any issues.

The issue that became apparent is this. I have several OpenVPN tunnels going out to different remote hosts from my openvpn router (call it openvpn1, having IP address of 192.168.1.2).  The opnsense router has a LAN interface address of 192.168.1.1 and I have a bunch of static routes defined on opnsense to route through openvpn1 gateway.  All is well, routes are working. Great.  The issue that I came across with the new opnsense in the mix is that any TCP connection that is routed by opnsense to the openvpn1 gateway breaks after about 20-30 seconds, and I can't for the life of me understand what is causing it.  Now I know that the opnsense is somehow causing this because to test, I added a static route on my machine and bypassed opnsense - the connections didn't break.  Once I removed the static route, the connection died immediately.  Any ideas what's may be happening here?

Thanks in advance,

-Eugene.

I ended up re-using an idle Dell T20 server with E3-1225 v3 @ 3.20GHz (4 cores) CPU. No problem handling 1gig at full throttle.  Albeit I only have one heavy user (me  ;D) seems to be holding up just fine where as the AMD GX 420 struggled under stress.  The AMD works just fine if you have < 350mbit bandwidth requirements.

Well, indeed mystery solved! I had a xeon machine with multiple NICs that did the trick. So indeed the CPU was the culprit. Thanks for the hint :)

I will try with an i7 i have laying around. However I did not see the CPU pegged during testing either with sensei on or off.

Hello everyone,

Just installed Sensei and noticed that it significantly reduced my overall bandwidth throughput while enabled (to the tune of 60-70% lower bandwidth  :o)  I am running on a HP T620 Plus thin client, AMD GX-420CA SOC (4 cores) with 16GB of RAM.  Issue was confirmed after disabling Sensei and re-running provider bandwidth test (Verizon FIOS 1Gbit connection).

Any thoughts?? I really like the level of detail Sensei provides, and I hope that this is something that can be resolved.  Thanks in advance!