<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Openbsd:  &#8216;interface groups and pf&#8217;</title>
	<atom:link href="http://stateless.geek.nz/2005/06/18/openbsd-interface-groups-and-pf/feed/" rel="self" type="application/rss+xml" />
	<link>http://stateless.geek.nz/2005/06/18/openbsd-interface-groups-and-pf/</link>
	<description></description>
	<lastBuildDate>Mon, 06 Feb 2012 01:02:40 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Nicholas Lee</title>
		<link>http://stateless.geek.nz/2005/06/18/openbsd-interface-groups-and-pf/comment-page-1/#comment-278</link>
		<dc:creator>Nicholas Lee</dc:creator>
		<pubDate>Sat, 18 Jun 2005 06:11:18 +0000</pubDate>
		<guid isPermaLink="false">http://stateless.geek.nz/2005/06/18/openbsd-interface-groups-and-pf/#comment-278</guid>
		<description>I think &lt;em&gt;&quot;pf is much easier to configure&quot;&lt;/em&gt;, is the important point.  Configuration of iptables is like trying to be your own mo-DEM. Ingress and egress in this situation I think is different slightly from the normal use. Egress above is basic the interfaces associated with the default route.  

So you can traffic filter and manage (using ALTQ no doubt) traffic on the default route both inwards/ingress (block &lt;strong&gt;in&lt;/strong&gt; on egress ...) and outwards.egess (block &lt;strong&gt;out&lt;/strong&gt; on egress ...).  Everything else is a matter of local policy.  

Obviously this is very useful for a laptop changing between wired and wireless, but maybe not so useful for a fixed server.</description>
		<content:encoded><![CDATA[<p>I think <em>&#8220;pf is much easier to configure&#8221;</em>, is the important point.  Configuration of iptables is like trying to be your own mo-DEM. Ingress and egress in this situation I think is different slightly from the normal use. Egress above is basic the interfaces associated with the default route.  </p>
<p>So you can traffic filter and manage (using ALTQ no doubt) traffic on the default route both inwards/ingress (block <strong>in</strong> on egress &#8230;) and outwards.egess (block <strong>out</strong> on egress &#8230;).  Everything else is a matter of local policy.  </p>
<p>Obviously this is very useful for a laptop changing between wired and wireless, but maybe not so useful for a fixed server.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard Parry</title>
		<link>http://stateless.geek.nz/2005/06/18/openbsd-interface-groups-and-pf/comment-page-1/#comment-279</link>
		<dc:creator>Richard Parry</dc:creator>
		<pubDate>Sat, 18 Jun 2005 05:45:19 +0000</pubDate>
		<guid isPermaLink="false">http://stateless.geek.nz/2005/06/18/openbsd-interface-groups-and-pf/#comment-279</guid>
		<description>That&#039;s pretty cool.

I think you can do something similar with Tables, but you need to chain a rule to an interface and point it to another, and that shit will send you blind just trying to work it out.

pf is much easier to configure, and with this function it should be cool.  Does it also support ingress?  That way you could have default lists for any sort of interface, both inbound and outbound traffic.</description>
		<content:encoded><![CDATA[<p>That&#8217;s pretty cool.</p>
<p>I think you can do something similar with Tables, but you need to chain a rule to an interface and point it to another, and that shit will send you blind just trying to work it out.</p>
<p>pf is much easier to configure, and with this function it should be cool.  Does it also support ingress?  That way you could have default lists for any sort of interface, both inbound and outbound traffic.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

