<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Unidirectional Firewall Rule?]]></title><description><![CDATA[<p dir="auto">Hello</p>
<p dir="auto">I am trying to find a way to create a firewall rule that only allows UDP traffic within a session to flow in one direction (i.e. disallowing any return packets within the session).<br />
I would like to replicate a similar action to a stateless firewall where if I have an allow rule, there isn't a silent secondary rule to allow return traffic within the same session (state).</p>
<p dir="auto">I am specifically trying to create this for UDP syslog traffic. Since the protocol itself never has return packets within a session, I would like to lock down the firewall rules even more by never allowing bidirectional traffic.</p>
<p dir="auto">Does anyone know how to create such a rule in pfsense?</p>
<p dir="auto">I have tried adding advanced options to my rules with states set to none and reply to set to no. I have also tried adding floating rules allowing WAN to LAN UDP syslog, then a rule before it blocking any packets flowing the other direction, but that still failed.</p>
]]></description><link>https://forum.netgate.com/topic/164801/unidirectional-firewall-rule</link><generator>RSS for Node</generator><lastBuildDate>Mon, 20 Apr 2026 06:11:01 GMT</lastBuildDate><atom:link href="https://forum.netgate.com/topic/164801.rss" rel="self" type="application/rss+xml"/><pubDate>Thu, 01 Jul 2021 11:46:12 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Unidirectional Firewall Rule? on Sun, 15 May 2022 14:06:27 GMT]]></title><description><![CDATA[<p dir="auto"><a class="plugin-mentions-user plugin-mentions-a" href="/user/t1lance24">@<bdi>t1lance24</bdi></a></p>
<p dir="auto"><em><strong>In case you never figured this out, or someone else stumbles across this on google.</strong></em></p>
<p dir="auto">You will need 2 rules placed in the “Floating” Rules tab. The first will block return traffic, and the second will be the allow rule. Important note: Both firewall rules must be applied to the same interface. Specifically, they must be both applied to the interface where the traffic is originally coming from (source).</p>
<p dir="auto">Example:</p>
<p dir="auto">Lets say we have a Syslog server at the IP of 192.168.0.10 listening on port 514. And we also have a client that wants to send Syslog messages to the server, and their IP is the 192.168.50.2. So we must allow traffic to pass from the 192.168.50.2 to the 192.168.0.10 on port 514 without allowing return communication.</p>
<p dir="auto">The options you will need set for each rule:</p>
<p dir="auto">BLOCK RESPONSE:</p>
<pre><code>Action: Block
Interface: WAN    #TrafficSourceInterface
Direction: Out
Protocol: UDP
Source: 192.168.0.10    #syslog server
Source Port: 514
Destination: 192.168.50.2     #syslog sender
Destination Port: any
Log: Log packets
State type: None
</code></pre>
<p dir="auto">ALLOW SYSLOG:</p>
<pre><code>Action: Pass
Quick: Apply the action immediately on match
Interface: WAN    #TrafficSourceInterface
Direction: In
Protocol: UDP
Source: 192.168.50.2     #syslog sender
Source Port: any
Destination: 192.168.0.10    #syslog server
Destination Port: 514
State type: none
</code></pre>
<p dir="auto">Should look something like below. I have this all configured on an internal firewall, with syslog senders outside my "WAN" so that will differ with other peoples setups.</p>
<p dir="auto"><img src="/assets/uploads/files/1652623317935-examplefwrule.png" alt="examplefwrule.png" class=" img-fluid img-markdown" /></p>
<p dir="auto">You can test this out using ncat in udp mode between two machines. Thats originally how I figured it out.</p>
]]></description><link>https://forum.netgate.com/post/1042265</link><guid isPermaLink="true">https://forum.netgate.com/post/1042265</guid><dc:creator><![CDATA[erasedhammer]]></dc:creator><pubDate>Sun, 15 May 2022 14:06:27 GMT</pubDate></item></channel></rss>