All,
I'm running a public syncthing relay server (https://docs.syncthing.net/users/strelaysrv.html (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 (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 (https://forum.syncthing.net/t/opnsense-rules-for-relay-server/19833)
At a guess, a combination of reasons would explain question 1 and you'll need to run some packet captures to confirm it. Please see https://docs.opnsense.org/manual/firewall.html
First of all, the floating rule will be evaluated first, this is important to note.
My guess is that the blocks are to do with some timing between packets from the application will send some of them out of order or more likely, after a time when the original state has been deemed expired. The way to check is to look at the TCP flags of the blocked packets.