Messages

Scratch this post. This looks like a dynDNS client issue on OPNSense that has lead me down the wrong path. Going to abandon it as it never worked properly after they stopped running the old client that was rock solid from day one! Will go back to the no-ip client on one of my web servers.

Hi,

I recently moved away from a FTTC connection to a FTTP connection. This has meant that my OPNSense WAN connection has now changed. It looks like this is now a NATed address as the interface IP is now on a 172.16.11.X address. The address that I actully have from an outside perspective is an expected Internet routeable IP. 2 issues have arisen from this new setup.

1. I'm interested, from a technical perspective, how this is working as I'm struggling to make the routing config they have in place make sense in my head. They are NATing and external IP behind an internal IP. I guess that makes sense, just never thought about it being done in reverse I guess.

2. More importantly, my Dynamic DNS setup on the firewall is, while technically working, and reporting my Internet routable IP as the IP to report into my Dynamic DNS provider (no-ip), devices on the outside of my network can't reach them. This, I suspect is because I use the WAN interface IP in the FW rule and the WAN interface IP is this 172 address.

This has essentially cut off all access to my internal web services. I'm not sure how I can resolve this. I've removed the default option to block private networks on my WAN interface as essentially all traffic inbound from the supplier provided modem will be coming from and RFC1918 address but this, I suspect is only half the solution.

Sure this must be a common problem so if anyone can share any pointers, I'd appreciate it.

Thanks.

Scratch that...

https://github.com/opnsense/core/commit/05b48c151547

With the latest update, I no longer seem able to use underscores in my alias names. See attached.

Anyone have the same issue?

[local host]

Sensei runs on inner-facing interfaces and determines the "remote" / "local" properties in terms of where the connection is initiated. If it comes from the LAN side, than the src ip address is considered local and dst ip address is regarded as "remote".

So if a connection is from a local host behind network A to a host behind local network B, sensei will consider the host on local network B as "remote", since for the context of the connection, it was the "remote end".

Obviously this is creating a bit confusion. Let us give this a bit of thought.

Yep that makes complete sense. Should have given that more thought before posting. I guess, you could build into an option to "Define local hosts" whereby we could add all addresses or subnets that we class as local and use them in the report. You couldn't just use RFC1918 as you'd end up with IPs on the end of VPNs being considered local. So easier said than done no doubt but if you were to use Logstash (you don't I know but as you're using an Elastic backend, the reference is somewhat valid), you could have all submitted "local addresses" assigned to a key/value pair file and import them into an array to use in the filter.

You'd loop through that array on each update of the report and if the source address existed in the KV pair, add a field called "local" then use than field as a key in the report for local connections. Given that very little thought until now so there are probably many reasons why that wouldn't work. Overhead for one thing... :-)

Spoke too soon. While the Service Tests Setting will apply, trying to apply the given "Service Settings" prevents me form applying the config. No error, no warning, just won't apply.

Awesome, thanks.

Hi Utah,

Thanks for the reply. It's only a basic layer 2 switch. No IPs tied to VLANs/ports. The issue was (much like the result of many of my posts here), resolved myself about an hour or 2 after posting. It was down to my own confusion about the way interface rules work. I have years of dealing with Palo FWs and the concept of zones. I was having a hard time converting in my head how OPNSense was dividing up interfaces but now I'm thinking that the interfaces are essentially zones in their own way. For example, I initially thought that putting a LAN rule in that says LAN can get anywhere on any protocol, also meant I needed to add a rule to the DMZ interface to say that the LAN can get to any host in the DMZ. Not the case, the "allow anywhere" rule in the LAN has by rights, allowed hosts on the LAN into the DMZ (and any other interface). It's just a different way of thinking about it I guess but I'm getting there. :-)

working under the belief that the interfaces worked

Hi,

I'd like to start using Monit but I'm really struggling to find good examples and walkthroughs to explain in detail how the components plug together. Granted, there is the FTP server restart example here: https://docs.opnsense.org/manual/monit.html but that only addresses restarting a failed service on OPNSense.

My initial requirement was that I wanted to monitor if a VPN had gone down and alert me via email if it had. I managed to find an official script that seems to do the job here: https://github.com/opnsense/core/pull/3025/files which I guessed I had to set up as a Custom Service Setting pointing to that script within OPNSense with a Test Setting of "ChangedStatus" (no idea if that's right as there is no guidance anywhere). Having done that, I now see it in the Monit Status page stating that the status is "OK". I'm not sure what exactly is "OK" as I've not asked it to monitor any gateway yet as far as I can tell.

The Service Test Settings for "ChangedStatus" are already configured to "Alert" so I assumed it would then pass it to the Alert stage and fire off an alert to the email address I have configured in my one and only alert (and yes, I have configured my email relay agent in the General tab and also set it up and tested it with Sensei so I know it's working).

Within the Alert config I have a drop down box of Events. I have no idea where these are pulled from. For example, there is an option in the Events drop-down for "Connection Failed" which its name would suggest is what I need but ultimately, I'm just blindly clicking on options hoping I'll get lucky (*I didn't get lucky...).

I'm sure those of you that have experience with Monit outside of OPNSense and have been tinkering for a while might think these questions are a bit amateur but coming into it blind, it is really not clear which options are supposed to tied to which component.

Thanks.

I had another suggestion/possible feature request. I build a fair number of dashboards using an Elasticstack cluster at work and noticed that you use the map to locate traffic destinations. I'm assuming you make use of the same DB that OPNSense does if you use the GeoIP alias (GeoLite2-Country-CSV)? I use the same setup for plotting traffic destinations at work except I use the GeoLite2-City-CSV. As you allow for the zooming in on the traffic map, might it be a suggestion to use a city IP locator instead of a country one? The map would look far more impressive if it split out the destinations into cities. At the moment, all my traffic bound for the US is ending up in Cheney Reservoir in Wichita!  ;)

[Question one]

I'd like to chime in with the same question and an additional question (plus a small cosmetic bug report at the end).

Question one
To give you specifics in the hope that it helps give you/me a better understanding of what is going wrong (or more likely what I'm missing), my setup is as follows:

• OPNSense running on an i5 NUC with 8GB RAM.
• 1 LAN subnet of 192.168.100.0/24 which is attached to the physical LAN in OPNSense.
• 1 DMZ subnet (192.168.50.0/24), which is a virtual interface (VLAN) hanging off the LAN interface of OPNSense.
• 1 Proxy server on the DMZ.
• 1 Guest network (192.168.150.0/24), which is a virtual interface (VLAN) also hanging off the LAN interface of OPNSense.
• 1 WAN interface using PPoE to a DSL modem.
• A Windows domain of around 10 Windows servers and multiple Linux servers with 2 Windows DNS servers sitting at 192.168.100.14 & 192.168.100.15.
• A Pihole running on the same subnet (192.168.100.18).
• Both Windows DNS servers have the Pihole set as their forwarder.
• DHCP is handled by the same Windows servers that handle DNS queries.
• OPNSense is set up as a DHCP relay for both the Guest and LAN subnets.
• Windows DHCP is set up to always update DNS so I can see all of the hosts, regardless of type, are being registered in DNS.
• DNS query route goes: Client --> Windows DNS --> Pihole --> Internet.

I've installed Sensei today and also added the DNS servers (192.168.100.14 & 192.168.100.15), under: Sensei/Configuration/Reporting & Data with the expectation that Sensei would check DNS for the hostnames of the IPs that are hitting the LAN interface. This doesn't appear to be happening and I'm not clear on why that is.
Further testing shows that if I use the FW to do DNS then I see the hostnames.

Is the only solution to this setup, to set the DNS in my DHCP scopes as the firewall then set the forwarder on the firewall DNS to be my Windows DNS servers (to keep the domain working), then the forwarder on the Windows DNS servers to be my Pihole docker container? That seems an overly excessive amount of DNS queries but it's the only way I'm seeing this working. This would be a pretty standard setup in most orgs in the sense that the first DNS host they query will always be the Windows DNS servers on the domain.

If this is the solution, then I don't understand why the option to allow the reverse lookup of IPs is present in Sensei.

Question 2
I am looking at the reports for "Top Remote Hosts" and I am seeing entries in there as FQDNs that are my internal hosts on the 192.168.100.0/24 subnet. Definitely not remote hosts. Interestingly, as Sensei is reporting the FQDN, it has to be getting that from my Windows DNS servers (I'm running split DNS so my domain is resolved internally), so it is able to query my DNS servers and retreive local addresses. Surely it should know that if the resolved address sits on a range that it knows it hosts on the LAN interface, it isn't remote. I'd almost accept it if the address was on my DMZ but even then, the DMZ (in my specific case here), is a virtual interface of the LAN so again, easy to spot that it's not Remote.
Or maybe I'm misunderstanding your meaning of "remote".  :)

Last question/bug report
Go to Sensei/Configuration/Reporting & Data
Click the small orange "i" next to: "Perform health check for indices:" and you'll see that the help section for "Connection Security" and the section for "Reporting Criteria" in the block below opens up with the explanation for setting the Reporting Criteria for the email reports. The same thing happens if you click the orange "i" for "You can erase reporting data:"

Sorry for the overly long post, thanks for making it this far! I look forward to any insight you can offer to the above questions.

Thanks.

Hi,

I have a 2 interface box, LAN and WAN and a DMZ as a virtual interface configured as a VLAN hanging off the LAN interface. Rules are in place and all seems to be working well say for one thing, the only host on the DMZ (192.168.50.0/24) is my Linux Proxy Server sat at 192.168.50.2. I've allowed the DMZ to get anywhere except for the LAN (192.168.100.0/24), allowing the DMZ host out to the web but keeping it from getting inside my LAN other than to the specified ports/IPs of internal resources.

However, the DMZ host (192.168.50.2) can still mount NFS shares on my ReadyNAS (192.168.100.4) which makes no sense because it can't get to any other host on the internal LAN. I'm been fiddling with this for 4 hours and I can't make any sense of it. I've even disabled all the DMZ rules to see which one it was firing on. I could still access my NAS on the LAN. I don't see how any other rule can be allowing this as the host is in the DMZ.

There is nothing in the FW logs with the IP of my NAS in it despite switching on logging for every rule I have.

Totally baffled as to how this is happening. so if anyone has any suggestions, it'd be appreciated.

Hi Maurice,

Thanks for you reply. You're correct. I meant to mark this post as "solved" when I realised my mistake some days ago.

Hi,

I have a working OPNSense setup, 3 VPNs, and a DMZ hanging off the only LAN interface. Everything works but I'm confused how the DMZ hosts are getting out to the Internet and it's bothering me.

• 
  I have a single WAN connection, 3 VPNs, one to my Azure infrastructure, one to another site for backup and one that routes specific hosts over IPVanish (hence the need for Hybrid setup of Outbound NAT rules).
  
• 
  One DMZ hung off the LAN interface.
  
• 
  I have a selection of Outbound NAT rules to allow VPNs to function as well as the Outbound NAT for my LAN subnet (192.168.10.0/24). My DMZ sits on the subnet 192.168.20.0/24.
  

Hosts on the LAN and the DMZ can access the Internet (which was my intention), but I have no Outbound NAT rule for the 192.168.20.0/24 subnet. Obviously the traffic is leaving on the only WAN interface available but for other corp FWs I've used up to now, you would have to define your subnet in the Outbound NAT rules. If I defined 192.168.0.0/16, I could understand why it worked but as I've defined a smaller, non overlapping subnet, I'm confused as to how DMZ traffic gets out.

Anyone care to point out what I'm missing?  :)

And therein is why you shouldn't be testing this stuff at 2:30am. I hadn't tagged in the DMZ ports.

All working now....