Messages

After investigation I have discovered that this is not an OPNsense issue. Not really surprising since this was only happening for the AlmaLinux servers that has two interfaces. I did not grasp that the AlmaLinux setup requires two default interface when moved to the DMZ, often referred as (hot) potato routing, or deflection routing. Though it currently works on the LAN interface, not sure why?

The modification to the AlmaLinux servers requires me to configure the routes to return the packets on the same route they arrived. One of the issues that I will face is that the WAN route is configured via PPPoE, there is currently a bug with the Firewalld service reload command not working with PPPoE complicating things: https://github.com/firewalld/firewalld/issues/878.

Perhaps there is an alternative approach with OPNsense for Running the AlmaLinux interface via the DMZ interface. I am open to suggestions. Thank you for reading this post.

Philippe

OPNsense 22.7.11_1-amd64
FreeBSD 13.1-RELEASE-p5
ESXi 7.0 Update 3

Hello VHunter,

Since I am new to this distro, I am most likely the last person to make suggestion on hardware compatibility for OPNsense.

You are correct in asking question about the CPU & GPU when you make an installation of software on metal. You have to make sure that all the hardware components are supported for the software that you are installing.

I also run OPNsense on ESXi but regrettably that does not answer you question. When running OPNsense in a vm on any type-1 hypervisor. It is the hypervisor server running on metal not OPNsense.

To come back to your question about AMD Ryzen... When I looked two years ago for a CPU that worked with ESXi. I chose the AMD Ryzen Threadripper 2950X, a CPU that was designed for multithreading not gaming. I believe at the time AMD also made a CPU line that was designed for gaming. Not to say that OPNsense will not work on a hardware gaming configuration. Just a heads-up that CPU and hardware is in general tuned for different purposes.

P.

Hello pmhausen,

Thank you for the reply. Yes I am aware of the reordering issue. From my experience it is not unique to OPNsense distro's.

What is a first for me is that I was not able to do the reassignment as you suggested in OPNsense without hosing my PPPoe WAN access permanently and I tried multiple times.

I took a different approach to the problem. Did an installation with two interfaces WAN(PPPoe) & LAN. Got that working and after I added the extra interfaces, currently a total of seven. Every time I added an interface, I let OPNsense do its reordering and made the reordering changes on the ESXi side instead. But as I mentioned above that created new problems. Even if these problems seem to be resolved this has peaked my interest? hence this post.

Regards,
Philippe

OPNsense 22.7.11_1-amd64
FreeBSD 13.1-RELEASE-p5
ESXi 7.0 Update 3
AlmaLinux 8.7

Hello All,

I am attempting to access a mail AlmaLinux 8 Server in the OPNsense DMZ zone from the LAN zone. The mail AlmaLinux 8 server was built with two interfaces to provide both public/WAN and private/LAN(private) accesses.

My OPNsense router configuration includes multiple zones/interfaces including WAN, LAN & DMZ zones. Obviously I have completely open all the involved firewall zones for solving this issue. I even created another AlmaLinux server(single interface) confirming access crossing from the LAN to the DMZ zones for the OPNsense router.

If the client accessing the mail server sits on the same subnet and zone as the mail LAN(private) interface, I have no access issues. But as soon as I move the mail server LAN(private) interface to the DMZ zone. I lose all LAN(private) accesses to the mail server. Hence: Traceroute from the OPNsense router, the mail server is found. Traceroute from a client in OPNsense LAN zone, the mail server is not found, the access stops at the OPNsense interface.

Thank you for reading this post.

P.

Hello All,

In regards to the following:

I added two more interfaces: Mgt and DMZ. I am back with what I believe the same problems.

I applied the same steps as described in my original post that I believe fixes the access to the interfaces and that worked again for this scenario. Not the most elegant solution since I can not explain the why. Thank you for listening.

P.

[The only thing that comes to mind as possibly being slightly unusual is I run a PPPoe interface for my WAN.]

OPNsense 22.7.11_1-amd64
FreeBSD 13.1-RELEASE-p5
ESXi 7.0 Update 3

Hello All,

I am evaluating OPNSense to replace my home Centos 7 Gateway. I have installed a Test OPNsense server. I have given it 2 cores hence 2 thread, 4 Gig of Memory and 10 Gig of disk space on zfs.

The good:
This is a pretty standard installation (for now) and it started with three interface WAN, LAN & Guest. The OPNsense gateway only sees Untagged frames at the interfaces. The setup uses ipv4, no VLAN configuration involved.  All appears to work as expected.

The bad:
I added an IoT interface and that is when my troubles started. Could only communicate with the IoT net via the Gateway. The LAN net was given full access but could not communicate via ICMP to the IoT net. The OPNSense gateway portal also became sluggish, took one minute to respond to many of my requests. Though the WAN and LAN network requests seem to communicate as expected. Now what makes things more confusing is the problem went away when I made a few changes and maybe more that I am not aware.

• I enabled the DHCPv4 service on the IoT interface
• Added a test Alma Linux server on the IoT interface network to request an IP from the above service that worked
• Added a DHCP Static Mappings to the above interface for the above test server.

The good:
The problems on the IoT interface went away and all seem to be functioning as expected. I equated the issue to my lack of expertise.

The bad:
I added two more interfaces: Mgt and DMZ. I am back with what I believe the same problems.

The hypothesis:
I can not be the first that have added interfaces with OPNsense. The problems that I have would have been flagged a long time ago. So what do I have that is different? The only thing that comes to mind as possibly being slightly unusual is I run a PPPoe interface for my WAN.

It seems to me that the routing to the new interfaces are broken when I add interfaces and I do not know how to verify this. I am going  to make a backup of this configuration(ESXi) and try do redo the same above steps as for the IoT interface... and see where that brings me? Thank you for reading about my woes...

P.