Messages

Perhaps the documentation is just outdated?

Is anyone able to provide guidance?

Can anyone confirm if this is a bug in the wizard? It's seems odd that the wizard didn't create an actual Interface for OpenVPN.

[However, if I manually create and enable it myself, and then restart the OpenVPN service (important), pings and other traffic will start working]

OPNsense is the default gateway for every subnet.

I think I've narrowed down what the issue is, looks to be a bug. As I mentioned in my first post, the setup wizard did not create an Interface for OpenVPN. However, if I manually create and enable it myself, and then restart the OpenVPN service (important), pings and other traffic will start working. I validated that this is the issue because the moment I disable the OpenVPN Interface, traffic stops on the clients.
Here's what the Firewall rules section shows for my interfaces, notice I actually have two OpenVPN interfaces: "OpenVPN" (created by the wizard, not actually an Interface), and the Interface I enabled under Interface -> Assignments (VPNtestinterface). This looks pretty weird, I can't imagine this is how it is designed to work.

[I also cannot ping the VPN client from the firewall itself or servers behind the firewall, even though firewall logs show the traffic being allowed.]

Good afternoon!
I went through several OpenVPN setup tutorials and am confident I have almost everything setup correctly (internal CA,  server certificate, OpenVPN Server with aforementioned server certificate, user with client certificate). I made a test connection from my phone using the OpenVPN client and importing the .ovpn profile. The connection was successful and I see it under the "Connection Status" tab.

This is where things get a little weird and I'm left with a few questions.
1. I've tried pinging back and fourth (from phone to servers, gateway, and vice versa). Looking through the firewall logs, I can see the traffic getting allowed. However, the response is never received. I ran a packet capture and checked it out in Wireshark and it said the same thing. I can see my ping requests going out (from VPN-ed client to the default gateway, or to a server it should have access to) but the response is never received. And this isn't unique to ping, I can't seem to receive any kind of response. But the traffic is definitely not getting blocked. I also cannot ping the VPN client from the firewall itself or servers behind the firewall, even though firewall logs show the traffic being allowed. I've tried pinging the client IP from all the different interfaces.

None of the tutorials I followed did anything with NAT so I'm thinking there may be a routing problem, but I don't know how to solve the problem. And this leads me into my seconds question...

2. I used the setup wizard to create the OpenVPN server. It did NOT create a new interface under Interfaces. However, looking at the interfaces under Firewall -> Rules, I do see a new one named "OpenVPN". But, if I go back to Interfaces and go to Assignments, I see that there is a new interface that is ready to be created. So I went ahead and added/enabled it. This resulted in a second OpenVPN interface being listed Firewall -> Rules.

Something tells me that I shouldn't do this, but I feel like the interface needs to be Enabled at the very least. Is there a reason why the Interface wasn't created by OPNsense but it still shows up under Firewall -> Rules?

3. During the setup for the OpenVPN server, it asked for the "IPv4 Tunnel Network" and the "IPv4 Local Network/s". I don't want the clients to have access to my LAN. I had already created a designated DMZ that I would allow them access to instead and put that CIDR into the IPv4 Local Network/s field. However, I don't understand the logic behind the "IPv4 Local Network/s" setting. I'm just going to create firewall rules for the OpenVPN interface to allow it access to where I want it to access. So what's the purpose behind this setting, why is it necessary? 

Hi all,

It seems I'm unable to reproduce the issue in a VM, which is configured to use the e1000 NIC.

I do know however, that Mellanox cards are not updated to use the new interface library 'iflib' in FreeBSD. The changes to fix the traffic graph in IDS/IPS mode are related to this generic library.

The "Out (bps)" does not appear to be populated with any data. Interestingly enough, the "Top hosts out (bps)" graph is populated.

Sensei is running on Guest and LAN interfaces.
Suricata is running on WAN interface.

What type of NIC are you using?

I will mention that traffic data is the responsibility of the driver, which might explain why I'm seeing varying results. I'll take a look to confirm.

Stephan

Dell Intel PRO/1000 VT Quad Port Server Adapter
https://www.amazon.com/gp/product/B002JLKNIW/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
Went with this because it was recommended for having the best compatibility.

Hi franco, really appreciate the reply. I did the update today as soon as I saw the news. The changelog says "21.1 (installed)", so I'd assume final 21.1. I'm not sure exactly what 21.1-RC1 is.

I've had problems with Sensei and IPS causing this data not to be reported in previous versions, but this latest version seems to have fixed most of those issues. Now it appears to just be the "Out (bps)".

Disabling IDS populated the WAN portion of the graph (IDS is configured only on WAN).
Disabling Sensei populated the LAN and Guest portion (Sensei is only configured on these).

I'd love to help in any way I can 

The "Out (bps)" does not appear to be populated with any data. Interestingly enough, the "Top hosts out (bps)" graph is populated.

Sensei is running on Guest and LAN interfaces.
Suricata is running on WAN interface.

I banged my head on the wall for awhile, but I finally figured it out. IN and OUT do not mean what I thought they meant. Everything is relative to the firewall, NOT the interface.

Therefore, the correct rule to geo block canada...the reason the direction is "IN" is because the traffic is coming INTO the router from the LAN, it's not going out of the router to the LAN.

^^for anyone else who was struggling with IN vs OUT

Update: problem fixed with hardware replacement

See pictures below.

What's going on here? Is this a known bug? The only module that works (partially) is reporting -> traffic.

Traffic Graph (dashboard): https://i.imgur.com/dOFLUyM.png
NetData (the spikes only go up to 6mbps, and not even during the testing time): https://i.imgur.com/OE8P1Hx.png
Reporting -> Traffic - partially working, graphs on top half zeroed: https://i.imgur.com/WeNIZOx.png
Reporting -> Insight - data way off, stating 14MB total traffic

But if you deny on the WAN, it shouldn't matter that it is accepted on the LAN because it won't make it out of the WAN.

I have noticed that the default LAN accept rules are inbound, and that is what I am trying to understand. Why are they "inbound"? Wouldn't you instead want to allow any OUTBOUND traffic, and keep the implicit deny for inbound traffic?

Unless "in" means "out" and "out" means "in", this doesn't make sense to me.

Please chime in if you think you can help my understanding.

[wouldn't it make sense to instead block outbound traffic]

Can you please elaborate on this? I thought by default, incoming connections were blocked unless explicitly permitted. Therefore, wouldn't it make sense to instead block outbound traffic?

Also, creating an outbound block rule in the LAN vs the WAN, I don't understand how they are necessarily different. If I create an outbound block rule for 8.8.8.8 on the LAN, traffic will still have to pass through the WAN if they wanted to try to reach 8.8.8.8, so why wouldn't a simple WAN outbound block to 8.8.8.8 suffice?

I don't understand your proposed rule. If the source is LAN net and the destination is Canada, how can the direction ever be "IN"?

I apologize for my lack of understanding, this is my first deep-dive into firewalls.

As a test, I created an alias for Canada (also did the MaxMind setup beforehand) and created a WAN rule as seen below: WAN out, any source, destination Canada alias, IPv4+IPv6, Any protocol, Reject.

However, nothing is getting blocked. I've ran a few simple tests such as going to google.ca, but so far no results.

https://i.imgur.com/QTNeOOS.png

That's unfortunate, but good to know. Just ordered this SATA M.2 WD Blue 3D NAND to replace, hopefully this problem doesn't affect everything that's in the M.2 form factor.

https://www.amazon.com/gp/product/B073SBX6TY/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1