<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>

<channel>
	<title>Gleb Kurtsou</title>
	<atom:link href="http://blogs.freebsdish.org/gleb/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.freebsdish.org/gleb</link>
	<description>Just another FreeBSD Committers Blogs weblog</description>
	<pubDate>Mon, 24 Nov 2008 21:39:19 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.5</generator>
	<language>en</language>
			<item>
		<title>ipfw: layer2 lookup tables</title>
		<link>http://blogs.freebsdish.org/gleb/2008/11/23/ipfw-layer2-lookup-tables/</link>
		<comments>http://blogs.freebsdish.org/gleb/2008/11/23/ipfw-layer2-lookup-tables/#comments</comments>
		<pubDate>Sun, 23 Nov 2008 00:32:38 +0000</pubDate>
		<dc:creator>gleb</dc:creator>
		
		<category><![CDATA[soc]]></category>

		<guid isPermaLink="false">http://blogs.freebsdish.org/gleb/?p=7</guid>
		<description><![CDATA[I had an opportunity to spend some extra time improving layer2 filtering.
I&#8217;ve extended lookup tables in ipfw to support several layer2 addresses for a single layer3 address/mask. It means that it&#8217;s possible to assign mac addresses to network (in case ip&#8217;s are dynamically distributed by dhcp or whatever). Besides, wildcard ip address &#8216;any&#8217; is supported, [...]]]></description>
			<content:encoded><![CDATA[<p>I had an opportunity to spend some extra time improving layer2 filtering.<br />
I&#8217;ve extended lookup tables in ipfw to support several layer2 addresses for a single layer3 address/mask. It means that it&#8217;s possible to assign mac addresses to network (in case ip&#8217;s are dynamically distributed by dhcp or whatever). Besides, wildcard ip address &#8216;any&#8217; is supported, and entries with wildcard ip can be used for layer2 filtering.</p>
<p>For example: </p>
<pre>
ipfw table 1 add 192.168.1.0/24 ether 00:11:11:11:11:11
ipfw table 1 add 192.168.1.0/24 ether 00:22:22:22:22:22
ipfw table 1 add 192.168.1.0/24 ether 00:33:33:33:33:33

# equivalent to: ipfw table 2 add <b>any</b> ether ...
ipfw table 2 add ether 00:11:11:11:11:11
ipfw table 2 add ether 00:22:22:22:22:22
ipfw table 2 add ether 00:33:33:33:33:33
ipfw table 2 add ether ff:ff:ff:ff:ff:ff

ipfw add 1000 allow ip from 'table(2)' to 'table(2)' <b>layer2</b>

# layer3
ipfw add 2000 allow ip from 'table(1)' to 'table(1)'
</pre>
]]></content:encoded>
			<wfw:commentRss>http://blogs.freebsdish.org/gleb/2008/11/23/ipfw-layer2-lookup-tables/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Layer2 filtering in pf</title>
		<link>http://blogs.freebsdish.org/gleb/2008/07/30/layer2-filtering-in-pf/</link>
		<comments>http://blogs.freebsdish.org/gleb/2008/07/30/layer2-filtering-in-pf/#comments</comments>
		<pubDate>Wed, 30 Jul 2008 10:16:34 +0000</pubDate>
		<dc:creator>gleb</dc:creator>
		
		<category><![CDATA[soc]]></category>

		<guid isPermaLink="false">http://blogs.freebsdish.org/gleb/2008/07/30/layer2-filtering-in-pf/</guid>
		<description><![CDATA[Instead of trying to describe all the changes regarding layer2 filtering in pf I&#8217;d better provide some examples.
Ethernet address can be specified for host or interface name:
pass in on bridge0 from 10.0.0.1 ether 00:11:11:11:11:11 to 10.0.0.2 ether 00:22:22:22:22:22
pass in on bridge0 from ($int_if:network) ether 00:11:11:11:11:11 to any
Ethernet addresses are supported in table entries:
table &#60;test&#62; persist [...]]]></description>
			<content:encoded><![CDATA[<p>Instead of trying to describe all the changes regarding layer2 filtering in pf I&#8217;d better provide some examples.</p>
<p>Ethernet address can be specified for host or interface name:<br />
<code>pass in on bridge0 from 10.0.0.1 ether 00:11:11:11:11:11 to 10.0.0.2 ether 00:22:22:22:22:22<br />
pass in on bridge0 from ($int_if:network) ether 00:11:11:11:11:11 to any</code></p>
<p>Ethernet addresses are supported in table entries:<br />
<code>table &lt;test&gt; persist {10.0.0.1 ether 00:11:11:11:11:11, 10.0.0.2 ether 00:22:22:22:22:22}<br />
pass on bridge0 from &lt;test&gt; to &lt;test&gt; keep state (ether)</code></p>
<p>Ethernet stateful filtering is handled specially.  Per rule flag is added to conditionally enable ethernet stateful filtering (disabled by default):<br />
<code>pass log on bridge0 from &lt;test&gt; to &lt;test&gt; keep state (ether)</code></p>
<p>With <i>keep state (ether)</i> enabled pf uses real source and destination ethernet addresses from the first packet to create the state and uses these addresses afterwards to match the state.</p>
]]></content:encoded>
			<wfw:commentRss>http://blogs.freebsdish.org/gleb/2008/07/30/layer2-filtering-in-pf/feed/</wfw:commentRss>
		</item>
		<item>
		<title>filtering on bridge</title>
		<link>http://blogs.freebsdish.org/gleb/2008/06/29/filtering-on-bridge/</link>
		<comments>http://blogs.freebsdish.org/gleb/2008/06/29/filtering-on-bridge/#comments</comments>
		<pubDate>Sun, 29 Jun 2008 19:48:24 +0000</pubDate>
		<dc:creator>gleb</dc:creator>
		
		<category><![CDATA[soc]]></category>

		<guid isPermaLink="false">http://blogs.freebsdish.org/gleb/2008/06/29/filtering-on-bridge/</guid>
		<description><![CDATA[There used to be a flaw in using ipfw on bridge interface. It&#8217;s impossible to distinguish incoming packets on member interface from incoming packets on bridge itself. For example consider two rules:
add 1 allow ip from any to any in recv bridge
add 2 allow ip from any to any in recv member
First rule will never [...]]]></description>
			<content:encoded><![CDATA[<p>There used to be a flaw in using ipfw on bridge interface. It&#8217;s impossible to distinguish incoming packets on member interface from incoming packets on bridge itself. For example consider two rules:<br />
<code>add 1 allow ip from any to any in recv bridge<br />
add 2 allow ip from any to any in recv member</code></p>
<p>First rule will never match. The logic is ok here (if you are aware of ipfw&#8217;s handling of interface options). But what do you expect if you disable filtering on member interfaces and perform filtering on bridge only. You expect rule 1 to match all incoming packets on bridge. It gets extremely annoying when using stateful filtering.</p>
<p>First time I came across this issue several years ago. But didn&#8217;t figure out how to fix it. At that time I&#8217;ve decided to switch to pf.</p>
<p>Actually ipfw is the only firewall that allow rules like<br />
<code>allow ip from any to any out recv if1 xmit if2</code><br />
Such tricks are possible because ipfw gets input interface from mbuf of a packet. pf for example relies on pfil to provide interface.</p>
<p>I&#8217;ve added a hack into if_bridge to work around it. It contradicts traditional ipfw behaviour a little but seems to be much more useful. I think patches are useful enough and can be commited into FreeBSD:</p>
<p><a href="http://perforce.freebsd.org/changeView.cgi?CH=143921">perforce.freebsd.org/changeView.cgi?CH=143921</a><br />
<a href="http://perforce.freebsd.org/changeView.cgi?CH=144238">perforce.freebsd.org/changeView.cgi?CH=144238</a></p>
]]></content:encoded>
			<wfw:commentRss>http://blogs.freebsdish.org/gleb/2008/06/29/filtering-on-bridge/feed/</wfw:commentRss>
		</item>
		<item>
		<title>incompatibility and some new features</title>
		<link>http://blogs.freebsdish.org/gleb/2008/06/22/4/</link>
		<comments>http://blogs.freebsdish.org/gleb/2008/06/22/4/#comments</comments>
		<pubDate>Sun, 22 Jun 2008 22:26:01 +0000</pubDate>
		<dc:creator>gleb</dc:creator>
		
		<category><![CDATA[soc]]></category>

		<guid isPermaLink="false">http://blogs.freebsdish.org/gleb/2008/06/22/4/</guid>
		<description><![CDATA[Yep. I&#8217;ve made some changes that break backward compatibility 
But I&#8217;ve tried not to break anything intentionally but to do a cleanup work.
First of all most of sysctl&#8217;s responsible for layer2 filtering were replaced by per interface flags.
net.link.ether.ipfw and net.link.bridge.ipfw are replaced by l2filter interface flag.
So sysctl net.link.ether.ipfw=1 became ifconfig if1 l2tag.
net.link.bridge.ipfw_arp was renamed to [...]]]></description>
			<content:encoded><![CDATA[<p>Yep. I&#8217;ve made some changes that break backward compatibility <img src='http://blogs.freebsdish.org/gleb/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /><br />
But I&#8217;ve tried not to break anything intentionally but to do a cleanup work.</p>
<p>First of all most of sysctl&#8217;s responsible for layer2 filtering were replaced by per interface flags.</p>
<p><em>net.link.ether.ipfw</em> and <em>net.link.bridge.ipfw</em> are replaced by <em>l2filter</em> interface flag.<br />
So <em>sysctl net.link.ether.ipfw=1</em> became <em>ifconfig if1 l2tag</em>.</p>
<p><em>net.link.bridge.ipfw_arp</em> was renamed to <em>net.link.bridge.pfil_layer2_arp</em></p>
<p>Introduced <em>l2tag</em> interface flag. It&#8217;s purpose is to add mbuf tag containing source and destination layer2 addresses to every packet passing through interface. Note that l2tag filtering against layer2 addresses is performed in layer3.</p>
<p>When invoked from layer2 ipfw <em>no longer</em> touches layer2 headers. So they following rule won&#8217;t work anymore:<br />
<em>ifpw allow ip from 10.1.1.1 to any src-ether 00:11:11:11:11:11 <strong>layer2</strong></em></p>
<p>ipfw <em>mac</em> option was replaced by to two options: <em>src-ether</em> and <em>dst-ether</em>. ipfw still accepts mac option but translates it into src-ether and dst-ether.</p>
<p>Lookup tables support layer2 addresses now:<br />
<em>ipfw table 1 add 10.1.1.1 ether 00:11:11:11:11:11<br />
ipfw allow ip from table(1) to any</em></p>
<p>ipfw <em>mac-type</em> was renamed to <em>ether-type</em>. Support for mac-type preserved.</p>
<p>Stateful filtering remains somewhat special. The problem here is that l2tag is added to a packet only in input path (when invoked from <em>ether_demux</em>). Such decision was intentional, mainly because it&#8217;s impossible to get tag added in output path without serious layer violations or entire pfil framework and packet handling redesign. That&#8217;s why a packet that has no l2tag attached, will pass against layer2 <em>dynamic</em> rule.</p>
<p>Dynamic rules (state created by the rule) do not check both source and destination layer2 address, but just the addresses specified by the rule created it. For example<br />
<em>ifpw allow ip from 10.1.1.1 to any src-ether 00:11:11:11:11:11 keep-state</em><br />
will create dynamic rule that checks only source ethernet address of a packet, but not destination. </p>
]]></content:encoded>
			<wfw:commentRss>http://blogs.freebsdish.org/gleb/2008/06/22/4/feed/</wfw:commentRss>
		</item>
		<item>
		<title>post #1 (just a test)</title>
		<link>http://blogs.freebsdish.org/gleb/2008/06/22/post-1-just-a-test/</link>
		<comments>http://blogs.freebsdish.org/gleb/2008/06/22/post-1-just-a-test/#comments</comments>
		<pubDate>Sun, 22 Jun 2008 14:40:55 +0000</pubDate>
		<dc:creator>gleb</dc:creator>
		
		<category><![CDATA[soc]]></category>

		<guid isPermaLink="false">http://blogs.freebsdish.org/gleb/2008/06/22/post-1-just-a-test/</guid>
		<description><![CDATA[I&#8217;m working on improving layer2 packet filtering in FreeBSD as a part of Google Summer of Code 2008.
See wiki for details.
Progress reports are to follow.
]]></description>
			<content:encoded><![CDATA[<p>I&#8217;m working on improving layer2 packet filtering in FreeBSD as a part of Google Summer of Code 2008.<br />
See <a href="http://wiki.freebsd.org/GlebKurtsov/Improving_layer2_filtering">wiki</a> for details.</a></p>
<p>Progress reports are to follow.</p>
]]></content:encoded>
			<wfw:commentRss>http://blogs.freebsdish.org/gleb/2008/06/22/post-1-just-a-test/feed/</wfw:commentRss>
		</item>
	</channel>
</rss>
