Messages

ok, think I got it.

Tried to reproduce again today. Initially it didn't occur, until I opened the web developer tools. Then, when I closed the web developer tools, it kept happening. Then I closed the tab and after about a minute no blocked events were logged anymore.

So I assume that my browser (Firefox 126 64-bit on Suse Tumbleweed) is doing 'something' to support web developer tools and this is not a regular issue (or a problem with my understanding of firewall rules/network configuration).

I have two VLAN's, a management VLAN and a server VLAN.

My workstation is (when I need it) connected to the management VLAN. In the server VLAN there is a pihole running.

To allow the workstation to make changes to the Pihole configuration, I have added a firewall rule that allows the workstation to connect. This works nicely. The dashboard page in Pihole automatically updates some statistics. In the webbrowser developer tools, network tab, I see these calls. They are all fine, with a proper response and http response code 200.

Now, when I use the live log view in Opnsense, I see that there are many calls from my workstation to my pihole on port 80 which are blocked. When I close the pihole browser tab, these logs stop.

How is this possible?

This is a screenshot of my firewall rules for management interface: https://drive.google.com/file/d/1mbvVggCpaEkpiRHNbVVrzjiVOxcGSB0f/view?usp=drive_link

This is a screenshot of a log entry where the traffic is blocked: https://drive.google.com/file/d/1Lmjj9pWRG9hRLlQ8JMriudlDTZXvyhQg/view?usp=drive_link

For some reason it matches the default deny / state violation rule. But why doesn't it match the (quick) rule I created to allow this traffic? And why is (from a functional perspective) pihole webinterface still working fine?

Thanks!

Unbound just reported the ip of the interface on which you asked it. So from the management vlan I got the management ip-address, but from the server vlan (thus pihole) unbount returned the ip that opnsense has on the server vlan.

I solved it as you do: enable the mentioned setting and add an override. Now when I'm in the pihole container the pihole returns the ip-address of the firewall at the management vlan.

i have setup multiple vlans. I have created a management vlan which provides access to the admin interfaces of all equipment.

In Opnsense at System => Administration => Settings, I have configured the  Listen Interfaces for the Web GUI to the management interface.

Now I can reach it (from a workstation that also is in the management vlan) properly by ip-address 192.1xx.<managementvlan>.1, but resolving it in dns returns 192.1xx.<servervlan>.1.

For DNS I'm using a pihole that has unbound as its upstream DNS server; unbound is on the opnsense box as a resolver. Pihole and unbound also are in the server vlan.

Why does it resolve on the server vlan, is that because pihole uses ubound and both are in there too?

Should I just add an override to pihole to resolve to the management vlan (which seems to work), or is there a better solution?

[server vlan]

I'm trying to set this up too, but need some help.

My setup is as follows:

server vlan running a pihole and unbound (on the opnsense box)

management vlan running all management interfaces, but also my desktop

The pihole uses unbound as the upstream dns server. I have created a firewall rule to allow hosts from the management vlan to connect to pihole on port 53.

When I add the port forward, a "nslookup www.tweakers.net 8.8.8.8" on the desktop does show up in the firewall logs as a redirect, and shows up in the pihole as being succesfully processed. Nevertheless, nslookup gives a connection error / timeout.

Doing a nslookup without any ip-address, just returns the proper response immediately.

As noted earlier in this discussion, I believe this might be because nslookup expects a response from 8.8.8.8, but gets it from the pihole. I tried to add an outbound nat rule, but have not been successful.

Anyone who could get me to the right direction? Help is greatly appreciated!

thanks for your reply!

I have used live view for some analysis. Looking at the last 10000 records, I just picked an external IP where my floating rule is hit:

https://drive.google.com/file/d/1xPajK1eJ73-MbatYlQqb651s2v8Ntdsg/view?usp=share_link

This is the incoming traffic:

https://drive.google.com/file/d/1Hshkr9EyR_XOKF3ugdHGsW82LTv0IGj1/view?usp=share_link

And outgoing:

https://drive.google.com/file/d/18qJZZXsbfylE9re8N7oQoLeiW2hJll3o/view?usp=share_link

What I notice is the long period between the two (a couple of minutes). The last one has the TCP flag 'R', which I found is for reset connection.

I haven't set any state timeouts or max states, I'm using the defaults everywhere. For my system:

https://drive.google.com/file/d/1BHEWEvvqu8rdKYQVq26v6CFJOaDxupGa/view?usp=share_link

So why is there a reset connection flag, and what is the impact of the long period between the two records?

All,

I'm running a public syncthing relay server (https://docs.syncthing.net/users/strelaysrv.html) in the following setup.

Opnsense box is acting as firewall/router/gateway/dhcp server to my WAN connection. My internal network consists of two VLAN's: DMZ and Internal. In the DMZ I have a raspberry pi that runs DietPi. The Pi runs the syncthing relay service on ports 22067 and 22070. The IP-Address of the pi is 192.168.20.2.

All traffic from my internal network to the internet is allowed (default opnsense behavior). I only use IPv4, both internal and on the WAN connection.

In Opnsense I have added two port forward rules, forwarding port 22067 and 22070 from the WAN address to the same ports on the Pi.

This seems to work at first sight, but when I was reviewing my firewall logs I noticed that a lot of traffic from 192.168.20.2:22067 to an-external-ip:a-random-port was blocked by a rule labelled 'Default deny / state violation rule'.

I think this issue might be related to the state table that the firewall uses to keep track of connections. This assumption is based on this discussion:

https://www.reddit.com/r/PFSENSE/comments/f7cc7p/syncthing_firewall_rules/

related documentation in opnsense:

https://docs.opnsense.org/manual/firewall.html#advanced

The solution that eventually worked out was creating one single additional floating rule:

• Action: pass
• interface: DMZ
• Direction: in
• Source: pi
• Source port: 22067
• Destination: any, any port
• Advanced options - State type: none

Now my questions are:

• Why is the traffic blocked and doesn't the simple port forward "just" work?
• Did I create any security risk by adding the floating rule?
• Is adding this floating rule the correct way of solving this in opnsense?

FYI, I did ask about this on the syncthing forum, where this behavior is seen as an issue with opnsense:

https://forum.syncthing.net/t/opnsense-rules-for-relay-server/19833