<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall">
    <title>gmane.comp.security.shorewall</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.shorewall/27893"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.shorewall/27892"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.shorewall/27891"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.shorewall/27889"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.shorewall/27888"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.shorewall/27887"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.shorewall/27886"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.shorewall/27885"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.shorewall/27884"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.shorewall/27883"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.shorewall/27882"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.shorewall/27881"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.shorewall/27880"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.shorewall/27879"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.shorewall/27878"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.shorewall/27877"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.shorewall/27876"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.shorewall/27875"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.shorewall/27874"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.shorewall/27873"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27893">
    <title>Re: DNAT issues after upgrade from 1.3.9b to4.4.27.3</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27893</link>
    <description>&lt;pre&gt;Thanks Robert, Tom!

just about every time i switched firewalls i power cycled the switches, 
cable modem, and ran arp -d &amp;lt;firewall&amp;gt; on the web server.  and did run 
pings and nslookups to make sure i was communicating and dns was 
working.  early on i had issues with the tinydns config, and i could 
only ping by IP address and not name, now name resolution is working.

i went through the FAQ before posting, did it again now.  does not mean 
that i am not misinterpreting or doing something stupid :)

*Answer:* That is usually the result of one of four things:

  *

    You are trying to test from inside your firewall -&amp;lt;sam&amp;gt; no - trying
    from a proxy in colorado and my att wireless

  *

    You have a more basic problem with your local system -&amp;lt;sam&amp;gt; don't
    think so, works with old firewall, gateway set to firewall

  *

    Your ISP is blocking that particular port inbound or, for TCP, your
    ISP is dropping the outbound SYN,ACK response. -&amp;lt;sam&amp;gt; don;t think
    so, works with the old firewall

  *

 &lt;/pre&gt;</description>
    <dc:creator>Sam Cappello</dc:creator>
    <dc:date>2012-05-22T15:08:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27892">
    <title>Re: DNAT issues after upgrade from 1.3.9b to4.4.27.3</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27892</link>
    <description>&lt;pre&gt;

Sam,

If Robert's tip doesn't solve your problem, check out the DNAT
troubleshooting tips in Shorewall FAQs 1a and 1b.

-Tom
&lt;/pre&gt;</description>
    <dc:creator>Tom Eastep</dc:creator>
    <dc:date>2012-05-22T01:30:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27891">
    <title>Re: DNAT issues after upgrade from 1.3.9b to4.4.27.3</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27891</link>
    <description>&lt;pre&gt;
Sam,

I'm not sure what you are running into, but if you did a quick swap and 
test, your switches may not have caught up to the changes by the time 
you tested.  I ran into that when doing a midday cutover to a new 
firewall.  You can avoid that by pinging from Leaf to the DNAT target 
and vice-versa.  Once you see those pings going, this is a non-issue.

Here is a rule from a functional firewall that is DNAT'ing traffic 
arriving on a specific interface (in this case the only one in zone 
net2) and a specific (fake) IP on that interface for you to compare to 
the old version of the rule.



On 5/21/2012 4:52 PM, Sam Cappello wrote:

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl042420&lt;/pre&gt;</description>
    <dc:creator>Robert K Coffman Jr. -Info From Data Corp.</dc:creator>
    <dc:date>2012-05-21T23:40:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27889">
    <title>DNAT issues after upgrade from 1.3.9b to 4.4.27.3</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27889</link>
    <description>&lt;pre&gt;Hi,
I have been running shorewall 1.3.9b on lrp Bering 1.0-rc4 for many 
years, and it is long overdue for upgrade.  So I have loaded the latest 
version of LEAF (Shorewall 4.4.27.3 on LEAF Bering-uClibc 4.2) on newer 
hardware,  and am trying to get it working.

the goal - i have 5 external IP addresses, and i have bound them to the 
external interface on the firewall and would like to be able to forward 
specific IPs and ports to different IP/port combinations in my DMZ, as i 
was tought by the Shorewall docs over 10 years ago :)

So far i think i have everything running except for issues with DNAT.  I 
can get out to the internet, VPN into my office, and tinydns/dnscache 
seem to be working.  but when i try and connect from the outside (VPN 
through a proxy at work or via my phone using att network) to any of the 
web or email ports i have open, it fails.  3rd party email monitoring 
complains about it too.  trying to access a web site from the outside 
yields a 502 bad gateway error.  i can ping the exte&lt;/pre&gt;</description>
    <dc:creator>Sam Cappello</dc:creator>
    <dc:date>2012-05-21T20:52:30</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27888">
    <title>Re: Lsm Failover</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27888</link>
    <description>&lt;pre&gt;
No problem.

-Tom
&lt;/pre&gt;</description>
    <dc:creator>Tom Eastep</dc:creator>
    <dc:date>2012-05-20T14:39:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27887">
    <title>Re: Lsm Failover</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27887</link>
    <description>&lt;pre&gt;My bad had a half finished entry in tcrules...Sorry

Mike


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Mike Lander</dc:creator>
    <dc:date>2012-05-20T04:01:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27886">
    <title>Re: Lsm Failover</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27886</link>
    <description>&lt;pre&gt;use
a
its
default
on
night.
this



Hi Tom,
The failover worked last night. However this morning with tcpoutgoiung 
empty. 
Squid was requesting pages through my failover ISP 'rea' in this case. 
I entered tcpgoing= to fix it for now.
After re-reading. I have changed restore defaultroute=No and changed 
providers.
Right now I think squids cache is fooling me so I will leave this for 
awhile and check
tonight.

before changes
#NAME   NUMBER  MARK    DUPLICATE       INTERFACE       GATEWAY             
    OPTIONS         COPY

rea     1       256     -               eth0            205.134.193.137     
    fallback
com     2       512     -               eth1            50.78.47.94         
 

New config I am trying&amp;gt;shorewall show routing is with the provider config 
here

#NAME   NUMBER  MARK    DUPLICATE       INTERFACE       GATEWAY             
    OPTIONS         COPY

rea     1       256     -               eth0            205.134.193.137     
    loose,fallback
com     2       512     -               e&lt;/pre&gt;</description>
    <dc:creator>Mike Lander</dc:creator>
    <dc:date>2012-05-19T20:39:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27885">
    <title>Re: Shorewall 4.5.4 Beta 3</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27885</link>
    <description>&lt;pre&gt;

Thanks, Steven.

-Tom
&lt;/pre&gt;</description>
    <dc:creator>Tom Eastep</dc:creator>
    <dc:date>2012-05-19T18:55:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27884">
    <title>Re: Shorewall 4.5.4 Beta 3</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27884</link>
    <description>&lt;pre&gt;
Tom

Confirmed, the patch corrects the issue.

Thanks.

Steven.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Steven Jan Springl</dc:creator>
    <dc:date>2012-05-19T18:42:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27883">
    <title>Re: Shorewall 4.5.4 Beta 3</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27883</link>
    <description>&lt;pre&gt;
I know. As Steven reported, the syntax in the previous mail did not
work; so I had to change it to include the [....].

You are very welcome.

-Tom
&lt;/pre&gt;</description>
    <dc:creator>Tom Eastep</dc:creator>
    <dc:date>2012-05-19T17:20:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27882">
    <title>Re: Shorewall 4.5.4 Beta 3</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27882</link>
    <description>&lt;pre&gt;I'm not the owner of the main mail but in your link about this theme the error replied by the author is the same as is in the link.

This link has not the same information of your last mail.


Thanks for your time tom. I'm in this mailing list a few day ago and you are the man who know everything!

Best regards.

Emiliano

Emiliano Vazquez  |  PcCentro S.R.L.        
Callao 80 | CP 1022 | C.A.B.A.     
Office: +54 (11) 4951-0203  / 4155
Celular: 15.6253.7165
Mail: emilianovazquez&amp;lt; at &amp;gt;gmail.com
Web: http://www.pccentro.com.ar

-----Original Message-----
From: Tom Eastep &amp;lt;teastep&amp;lt; at &amp;gt;shorewall.net&amp;gt;
Date: Sat, 19 May 2012 09:42:31 
To: &amp;lt;shorewall-users&amp;lt; at &amp;gt;lists.sourceforge.net&amp;gt;
Reply-To: Shorewall Users &amp;lt;shorewall-users&amp;lt; at &amp;gt;lists.sourceforge.net&amp;gt;
Subject: Re: [Shorewall-users] Shorewall 4.5.4 Beta 3

On 05/19/2012 09:23 AM, Tom Eastep wrote:

Updated release notes text is:

2)  With some misgivings, this release adds support for the geoip match
     feature available in xtables-addons. Geoip allows matching of the
     source&lt;/pre&gt;</description>
    <dc:creator>emilianovazquez&lt; at &gt;gmail.com</dc:creator>
    <dc:date>2012-05-19T16:58:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27881">
    <title>Re: Shorewall 4.5.4 Beta 3</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27881</link>
    <description>&lt;pre&gt;
Updated release notes text is:

2)  With some misgivings, this release adds support for the geoip match
     feature available in xtables-addons. Geoip allows matching of the
     source or destination IP address by ISO 3661 country codes.

     The support is implemented in the form of extended syntax in the
     SOURCE and DEST columns.

     To specify a single country code, prefix it with a caret ('^')
     (e.g., ^A1).

     To specify multiple country codes, enter them as a
     comma-separated list enclosed in square brackets ('[...]') prefixed
     by a caret ('^') (e.g., ^[A1,A2]).

     Example - Drop email from Anonymous Proxies and Satellite Providers:

     #ACTION      SOURCE DESTPROTODEST
     #   PORT(S)
     DROP:info   net:^[A1,A2]dmztcp25

     A listing of two-character country codes is available at
     http://www.shorewall.net/ISO-3661.html.

-Tom
&lt;/pre&gt;</description>
    <dc:creator>Tom Eastep</dc:creator>
    <dc:date>2012-05-19T16:42:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27880">
    <title>Re: Shorewall 4.5.4 Beta 3</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27880</link>
    <description>&lt;pre&gt;
&amp;lt;Tom hits forehead with palm&amp;gt;

Clearly the country list needs to be delimited. The attached patch 
allows a single country code to be entered as ^cc and a list as ^[cc,...].

-Tom
&lt;/pre&gt;</description>
    <dc:creator>Tom Eastep</dc:creator>
    <dc:date>2012-05-19T16:23:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27879">
    <title>Re: Shorewall 4.5.4 Beta 3</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27879</link>
    <description>&lt;pre&gt;

Tom

Specifying two country codes as in the above example produces the following 
error message:

ERROR: Unknown Host (A2) /etc/shorewall2/rules (line 182)

Steven.


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Steven Jan Springl</dc:creator>
    <dc:date>2012-05-19T15:58:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27878">
    <title>Re: Squid Question</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27878</link>
    <description>&lt;pre&gt;
Yes, to both questions -- except that the tcrule isn't relevant. Squid
will use your 'balance' provider so long as it is up. Then it will use
the fallback provider.

-Tom
&lt;/pre&gt;</description>
    <dc:creator>Tom Eastep</dc:creator>
    <dc:date>2012-05-19T00:25:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27877">
    <title>Squid Question</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27877</link>
    <description>&lt;pre&gt;Tom,
Sorry to be such a nusiance. Now that I have a good chance to get my 
failover,
working. I think I can figure out how to get tunneils back up on my own.
But for many years I have ran squid as a transparent proxy by entering
the net zones ip in squid.conf transparent proxy section. IF I recall
tcrules would not route this right and you had to enter tcpoutgoing to 
work.
Currently my tcrules have this as its only entry so far.
providers with track=yes and balanced assumed with use defaultroute=yes

rea     1       256     -               eth0            205.134.193.137     
   fallback
com     2       512     -               eth1            50.78.47.94


tcrules
512:P                   0.0.0.0/0
512                     $FW

I need webrowsing to work as well. If I leave tcpoutgoing empty or blank

When comcast is up will squid honor the tcrule below?
And use comcast exclusivly?
 512                     $FW

I am pretty sure that squid will work when the firewall is in failover 
state
if tcpouting is empty?&lt;/pre&gt;</description>
    <dc:creator>Mike Lander</dc:creator>
    <dc:date>2012-05-18T23:39:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27876">
    <title>Re: Lsm Failover</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27876</link>
    <description>&lt;pre&gt;

Mike,

My configuration has changed quite a bit since I published that article. 
Then, the default gateway was at the provider's facility and not local. 
Now my default gateway is local on one uplink so I ping the next hop 
router and use TTL=2 on that provider. The problems I have encountered 
are almost always between my house and the provider, so doing it that is 
adequate and there are always the proper routes in place.

-Tom
&lt;/pre&gt;</description>
    <dc:creator>Tom Eastep</dc:creator>
    <dc:date>2012-05-18T22:06:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27875">
    <title>Re: Lsm Failover</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27875</link>
    <description>&lt;pre&gt;Tom,
I have one last question about this, I noticed that in your config. You use 
the default gateway of your ISP's.
Many times I have had various isp's fail. I ping the default gateway as a 
test. 99% of the gateway replies,
because they are static. Then I try something downstream and of course its 
down.
In your case does your failover work because its dhcp? And your default 
gate is not active in your comcast modem?

The reason I ask is originally I had entered the next downstream hop on 
both these ISPs when I started 
testing. I used the common open dns servers as a last resort last night. 
(4.2.2.2) (They always answer pings.)
Since I now know that lsm did not have the correct routes &amp;gt; inferface, this 
has been my trouble.

Mike


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint &lt;/pre&gt;</description>
    <dc:creator>Mike Lander</dc:creator>
    <dc:date>2012-05-18T21:08:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27874">
    <title>Re: Lsm Failover</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27874</link>
    <description>&lt;pre&gt;
Tom,

Makes perfect sense. I was not aware of that. 

Thank you,

Mike




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Mike Lander</dc:creator>
    <dc:date>2012-05-18T20:18:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27873">
    <title>Re: Lsm Failover</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27873</link>
    <description>&lt;pre&gt;doesn't
unknown
I also might add this incase of any bearing on trouble here. I was up late 
testing this more so if comcast failed. 
It seem to have the same issue, ie lsm cant ping its downsteam ip when 
disable is in effect in shorewall. 
This morning a live real failure occured on the failover isp.(rea) I had 
forgot to stop lsm last night. 
They called and woke me up complaining the ipsec tunnel was down.
When it failed I had modifed lsm in the way below when it failed live.
(may not have any bearing on trouble not sure)
#!/bin/sh
#
# (C) 2009 Mika Ilmaranta &amp;lt;ilmis&amp;lt; at &amp;gt;nullnet.fi&amp;gt;
# (C) 2009 Tom Eastep &amp;lt;teastep&amp;lt; at &amp;gt;shorewall.net&amp;gt;
#
# License: GPLv2
#

STATE=${1}
NAME=${2}
CHECKIP=${3}
DEVICE=${4}
WARN_EMAIL=${5}
REPLIED=${6}
WAITING=${7}
TIMEOUT=${8}
REPLY_LATE=${9}
CONS_RCVD=${10}
CONS_WAIT=${11}
CONS_MISS=${12}
AVG_RTT=${13}

if [ -f /usr/share/shorewall-lite/lib.base ]; then
    VARDIR=/var/lib/shorewall-lite
    STATEDIR=/etc/shorewall-lite
else
    VARDIR=/var/lib/shorewall
    STATEDIR=/etc/shorewall
fi

[&lt;/pre&gt;</description>
    <dc:creator>Mike Lander</dc:creator>
    <dc:date>2012-05-18T20:13:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.shorewall/27872">
    <title>Re: Lsm Failover</title>
    <link>http://permalink.gmane.org/gmane.comp.security.shorewall/27872</link>
    <description>&lt;pre&gt;
Okay.

You need to use your distribution's network configuration facilities
to add a route to 4.2.2.2/32 via the default gateway on eth0 and a
route to 4.2.2.1/32 via the default gateway on eth1.

It's important that traffic to the 'checkip' address be routed out of 
the correct interface even when that interface is unusable. That's the 
only way that LSM can determine when the interface comes back up.

-Tom
&lt;/pre&gt;</description>
    <dc:creator>Tom Eastep</dc:creator>
    <dc:date>2012-05-18T20:11:03</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.security.shorewall">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.security.shorewall</link>
  </textinput>
</rdf:RDF>

