Messages

Just wanted to provide some feedback to the 20.7 and ultimately 20.7.1.

We had been running 20.1.x for a while and once we were notified that the 20.1.x series had come to an end in the upgrade dialog we waited for a while until the point release came out with fixes for the initial release of 20.7

The upgrade went perfectly and after a few reboots during the process OPNsense was back up and running no config issues. We then upgraded to the latest 20.7.1 and all is well. All upgrades were via the web client.

The only feedback would be a little more information on the screen stating you need to wait for a while when initiating the upgrade. Our OPNsense runs in a VM on one of our DELL R710 servers and has CPU X5650 @ 2.67GHz (4 cores) and 4 GB of memory. This talks directly to our managed switch on the lan side and our Cisco router on the WAN side.

We were a client of Untangle for over 10 years but they had no intelligent path to IP6 and it seems little interest.

Cheers
Spart

In that case, it might be worth applying the fix also mentioned in that thread.
Down the bottom there's a fix that should apply for 20.1.7

As this is a production router I will wait for the formally tested fix to work through the testing and release cycle.

Cheers
Spart

So.. This looks to be a fairly similar issue to this one https://github.com/opnsense/core/issues/2841.

Could you try this as mentioned by AdShellevis:
"Can anyone with the issue try to disable "Automatic outbound NAT for Reflection" in Firewall->Advanced and test again? As far as I can see that's these are the only areas in the code generating a rule with as target an interface."

That tracks with what we did to try and get reflection working. We set  Automatic outbound NAT for Reflection on and reflection is now working for the lan.

If we disable it Nat reflection does not work.

Cheers
Spart

We are getting this warning message continually. See attached screenshot.

Can anyone decode this message so we can get rid of it.

Cheers
Spart

I have enabled IPDS and download and enabled some lists. It all looks like it worked but I cannot see any reports or activity on the IPS or IDS filters.

No graphs or other log or alert information. We have a mail server under constant attack so expect to see at least some activity. I ticked log to syslog but cannot see how to look at syslog,

Any help appreciated.

Cheers
Spart

The NAT reflection only creates the reflection rules, but does not open the ports from your internal interface(s) to the selected target.

You will need to add the rules on your internal interfaces too to allow the traffic on port 465,587,993. At least that is how i have it. So on Firewall -> Rules -> your INTERNAL interfaces -> add a rule like:

IPv4+6 TCP    *    *    This Firewall    465    *    *

greets
KoS

The ports must be open or there would be no access from outside. 'this firewall' is that the LAN or WAN address.

The default LAN IN rule lets me get OUT to anywhere from inside.

Are you saying I need a LAN OUT rule to point at these ports?

I have an error message that is repeating and makes no sense to me but seems somehow related to this issue.

@KoS

Thanks for the reply.

A bit confused though as the ports are defined for the Port forwards and FW rule. Example:

forward PUBLIC IP ports 465,587,993 to INTERNAL IP on ports 465,587,993 this works perfectly for out to in comms. When reflection set this creates a rule in the FW to allow traffic to the internal server.
FW Rule
   IPv4 TCP   *   *   zimbra    zimbra_ports     *   *   Allow connections to zimbra server

PF Rule that created the above is:

WAN   TCP   *   *   PUBLICIP  zimbra_ports     zimbra  zimbra_ports     Allow connections to zimbra server

What are we missing? Is there an example you can show. This will avoid having to manually hardcode all mappings in the dnsmaq overrides.

Cheers
Spart

Yes we are very familiar with using hardcoded names in the host file. Not having to do that manually for all port forwards would have been a significant time and complexity feature.

It also seems we now have to flush the caches of any user machine that has recently tried to connect to the url of that server as they will have gotten the Public IP of the service and not the internal IP from the hardcoded host overrides.

So the aim of alias goes out of the window as we now have to hard code the servers anyway! I did a scan and the forums on here are full of people who cannot get it to work. With no solutions or root cause identified.

Thank you anyway this is what we were trying to avoid!

Cheers
Spart

So basically it doesn't work! I am using dnsmasQ

I have to put internal host entries into the DNS server to point at my internal servers using FQDN's?

Cheers
Spart

Hello,

WE have a port forward rule that allows connection into a web and mail server. It works perfectly from outside.

WE turned on reflection for this rule so anyone inside the LAN going to the web server or mail server on this host would be able to use the FQDN to get  to it as if they were outside.

However this does not work and trying to connect to the web or mailserver from inside just times out with a site can't be reached message.

The rules look fine, it does work form outside but no internal reflection.

Any help appreciated as this is the first use case we have tried and we have many more to configure so really need to get this to work.

Cheers
Spart

@marjohn56

Many thanks for the reply.

The Cisco has a static IP config /29 network. It takes the upper address as its GW address. Its not really handing out the addresses as much as it part of and is configured as the GW for this /29 network.

The em0 OPNSense WAN interface is on the same /29 subnet and is also taking one of the addresses and uses the cisco as its GW address.

All lights indicate all is well. The WANGW in the gateway monitor is showing down and we could not get the monitor to start. Its as if the /29 network is down. But all indications show it up at the cisco etc.

Will have another attempt but we have maybe been confused by the way the rules etc. work here.

We did think about reclaiming one of the used /29 addresses and bridging the em0 WAN interface to the cisco. BUt tht looked like we would lose all the functionality on the WAN interface and have to do that in the cisco (hard work)!

Cheers
Spart

Hello OPNSensers,

I have been a client of Untangle for 10 years. I like it it works and is very intuitive. However in the modern ip6 world we are just moving to it is sadly lacking with no indication that anyone cares.

So time to find a new FW/IPS/IDS perimeter security and network services platform.

After looking around OPNSense seemed like a good bet.

Maybe we have been too many years thinking in the untangle world. We configured a basic (or what we thought was a basic) system 2 interfaces LAN & WAN our architecture is as follows.

CISCO VDSL <-> em0 WAN OPNSENSE LAN em1 <-> MANAGED SWITCH <-> DEVICES

The CISCO VDSL device gets a /29 IP4 block takes one for itself as the GW. em0 gets one as the WAN port these 2 are directly connected. Nothing else is connected to the CISCO. We configured IP Aliases for the rest of the usable ip4/29 block on the WAN interface. so it has 5 usable /29 addresses including itself.

The OPNSENSE em1 is connected to the MANAGED SWITCH on the lan and is configured to provide DHCP for the lan segment and dnsmasq services for DNS and PXE Booting. Public upstream DNS servers are configured on the WAN interface and in dnsmasq. PXE booting works fine and serves the lan from our internal PXE boot server.

We have a number of services on the lan we expose publicly (web/email etc.)

When OPNSense boots everything seems to come up fine. However the dashboard shows WANGW as down. We cannot seem to get a connection through the OPNSense platform to the CISCO or it appears that way.

We used PortForward rules as we do on the untangle box to provide tunnels through for the public services. These look a bit weird and we may have configured them wrong.

We are used to saying something like.

Connect from anywhere to WAN IP xxx.xxx.xxx.xxx on ports 143,993 using TCP forward that to LAN IP XXX.XXX.XXX.XXX on ports 143.993

When we configure the PF as above we get that in the PF dialog but a rule in the FW on the WAN seems to show the internal IP's and Ports and not the external destination address. Anyway after bringing the network down for 30 mins by unlugging the connections into untangle and replugging into the OPNsense box. We had also spoofed the MAC addresses to match the UT box to avoid any issues.

We could not get anything in or out of the OPNSense box. We could get DHCP served internally and PXE Boot worked perfectly. No DNS resolution. So we know the LAN side is working the default allow all inside to outside should have got us out. But maybe not the return. Surely if we established from inside the OPNSense would nat that outside and we would get a return through but nothing.

We could not see the CISCO it seems. It thought all was well and the interface was up in the CISCO.In OPNSense the WANGW was still showing as down.

At that point best laid plans gone to s**t we had to replug the untangle and life was restored in a few seconds.

What are we missing. Is this not configured OOTB to allow lan out and block outside in. When we poked holes we expected to get traffic immed through to the mail cloud and web servers but nothing from outside via 4G network. We certainly expected to be able to browse a website from the LAN.

We did a lot of reading before we took this leap.

Any help and guidance appreciated as we really want to get off the old platform and move into the new IP6 world. Please forgive any typos this is a dump of what we found.

Cheers
Spart