<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Connmark on Inliniac</title>
    <link>https://inliniac.net/blog/tag/connmark/</link>
    <description>Recent content in Connmark on Inliniac</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Mon, 12 Nov 2007 21:29:58 +0000</lastBuildDate>
    <atom:link href="https://inliniac.net/blog/tag/connmark/feed.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Multiple Snort_inline processes with Vuurmuur</title>
      <link>https://inliniac.net/blog/2007/11/12/multiple-snort_inline-processes-with-vuurmuur/</link>
      <pubDate>Mon, 12 Nov 2007 21:29:58 +0000</pubDate>
      <guid>https://inliniac.net/blog/2007/11/12/multiple-snort_inline-processes-with-vuurmuur/</guid>
      <description>&lt;p&gt;One of the cool things of the &lt;a href=&#34;http://snort-inline.sf.net/&#34;&gt;Snort_inline&lt;/a&gt; project is the support for NFQUEUE. NFQUEUE is the new queuing mechanism to push packets from the kernel to userspace so a userspace program can issue a verdict on it. What makes NFQUEUE cooler than it&amp;rsquo;s predecessor ip_queue is that it supports multiple queue&amp;rsquo;s. This means that there can be more than one Snort_inline process inspecting and judging traffic. The challenge is to make sure that each Snort_inline instance sees all traffic belonging to a certain connection so Snort_inline can do stateful inspection on it. Luckily, &lt;a href=&#34;http://www.vuurmuur.org/&#34;&gt;Vuurmuur&lt;/a&gt; makes it very easy.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Vuurmuur NFQUEUE support</title>
      <link>https://inliniac.net/blog/2007/05/22/vuurmuur-nfqueue-support/</link>
      <pubDate>Tue, 22 May 2007 13:21:23 +0000</pubDate>
      <guid>https://inliniac.net/blog/2007/05/22/vuurmuur-nfqueue-support/</guid>
      <description>&lt;p&gt;Vuurmuur supported the QUEUE target for a while already, even though it needed a little bit of a hack to handle the &lt;em&gt;state&lt;/em&gt;. This is because the iptables ruleset Vuurmuur creates is quite simple: after a few general protection rules it starts by accepting traffic with the state &lt;em&gt;established&lt;/em&gt;. Since there is no way to say &amp;lsquo;queue established traffic that was queued before&amp;rsquo; in iptables I decided to use traffic marking to distinguish between traffic to be queued or accepted. But there was a problem with this approach. I didn&amp;rsquo;t want to cripple the marking of traffic for other purposes, such as traffic shaping and routing, so I decided to use mark-ranges to either queue or accept:&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
