Syncthing relay traffic out blocked?

[SVMartin80]

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

[cookiemonster]

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.

[SVMartin80]

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?