<?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.firewalls.netfilter.general">
    <title>gmane.comp.security.firewalls.netfilter.general</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general</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.firewalls.netfilter.general/46098"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46097"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46096"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46095"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46094"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46093"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46092"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46091"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46090"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46088"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46085"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46084"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46083"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46080"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46079"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46076"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46074"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46073"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46071"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46069"/>
      </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.firewalls.netfilter.general/46098">
    <title>(unknown)</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46098</link>
    <description>&lt;pre&gt;


Loan Syndicacion

Am AFG Guaranty Trust Bank, zu strukturieren wir Kreditlinien treffen Sie
unsere
Kunden spezifischen geschäftlichen Anforderungen und einen deutlichen
Mehrwert für unsere
Kunden Unternehmen.
eine Division der AFG Finance und Private Bank plc.

Wenn Sie erwägen, eine große Akquisition oder ein Großprojekt sind, können
Sie
brauchen eine erhebliche Menge an Kredit. AFG Guaranty Trust Bank setzen
können
zusammen das Syndikat, das die gesamte Kredit schnürt für
Sie.


Als Bank mit internationaler Reichweite, sind wir gekommen, um Darlehen zu
identifizieren
Syndizierungen als Teil unseres Kerngeschäfts und durch spitzte diese Zeile
aggressiv sind wir an einem Punkt, wo wir kommen, um als erkannt haben
Hauptakteur in diesem Bereich.


öffnen Sie ein Girokonto heute mit einem Minimum Bankguthaben von 500 £ und
Getup zu £ 10.000 als Darlehen und auch den Hauch einer Chance und gewann
die Sterne
Preis von £ 500.000 in die sparen und gewinnen promo in may.aply jetzt.


mit dem Folowin&lt;/pre&gt;</description>
    <dc:creator>AFG GTBANK LOAN</dc:creator>
    <dc:date>2013-06-17T19:33:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46097">
    <title>'Invalid packet' problem since upgrading</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46097</link>
    <description>&lt;pre&gt;I'm not sure if this is an iptables issue or an Ubuntu issue.

I have a PC acting as a firewall and router, using iptables. We have a
Wii-U inside the network and until a few days ago, it had no
connectivity problems at all. I upgraded the firewall PC from Kubuntu
10.04 to 12.04 and suddenly the Wii-U cannot connect.

It would appear that this is not a problem with the Wii-U. If I connect
it directly to the Optimum modem, everything works fine. It's something
wonky with the Kubuntu PC, since I upgraded. Nothing in my
iptables.rules has changed. I'm using the same set of rules as before
the upgrade.

I called Nintendo tech support and they insist that there is nothing
special that needs to be done. Their solution was to put it in a DMZ but
I'd rather not do that if I can avoid it.

I do an internet connection test in the Wii-U and it passes but it can't
connect to any services which require talking to the nintendo network,
such as Hulu, Netflix, the Nintendo e-shop and quite a few games.

I also have several &lt;/pre&gt;</description>
    <dc:creator>Allen Seelye</dc:creator>
    <dc:date>2013-06-17T13:36:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46096">
    <title>RE: Quick help with stateless firewall</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46096</link>
    <description>&lt;pre&gt;There are no ICMP rules at all in your example , I would reckon you need 2 rules on a stateless firewall ( atleast ).

ONE for ICMP type 8 on OUTPUT ( your machine sending ECHO REQUEST ) , not need as long as you have ACCEPT for all OUTPUT .
and ONE for ICMP type 0 on INPUT ( other machines sending ECHO REPLY back to your machine ) .

/sbin/iptables -A OUTPUT -p icmp -icmp-type 8 -j ACCEPT
/sbin/iptables -A INPUT -p icmp -icmp-type 0 -j ACCEPT

If you want others to be able to ping your machine you do the reverse way with the rules !

And since you ONLY need 2 services , you may want to remove this rule 
/sbin/iptables -A INPUT -p tcp --dport 1000:65535 -j ACCEPT

If you need to allow for outgoing return traffic you should allow source-services you need/use .
/sbin/iptables -A INPUT -p tcp --sport 80 --dport 1025:65535 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --sport 53 --dport 1025:65535 -j ACCEPT
/sbin/iptables -A INPUT -p udp --sport 53 --dport 1025:65535 -j ACCEPT

And same for OUTPUT ( unless you contin&lt;/pre&gt;</description>
    <dc:creator>André Paulsberg</dc:creator>
    <dc:date>2013-06-17T07:23:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46095">
    <title>Re: Quick help with stateless firewall</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46095</link>
    <description>&lt;pre&gt;IPv4 doesn't work very well without ICMP; generally, one should always accept 
it, in and out. However, it's OK to drop icmp-type=8 (ECHO requests) on input 
from non-local sources when the system should not respond to pings from 
others.

On Saturday, June 15, 2013 07:50:34 PM Bryan Harris wrote:
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Neal Murphy</dc:creator>
    <dc:date>2013-06-16T01:17:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46094">
    <title>Re: Quick help with stateless firewall</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46094</link>
    <description>&lt;pre&gt;I think you need this,

iptables -I INPUT -p icmp --icmp-type 8 -j ACCEPT

You can also do -j LOG to see what makes it to a certain place in the chain.

Bryan

On Jun 15, 2013, at 7:38 PM, Alex Flex &amp;lt;aflexzor&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Bryan Harris</dc:creator>
    <dc:date>2013-06-15T23:50:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46093">
    <title>Quick help with stateless firewall</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46093</link>
    <description>&lt;pre&gt;Hello,

I have the following simpel stateless firewall... the issue is iam not 
able to send ICMPs queries from within the machine. What could I modify 
or add for this to be able to happen .  Also iam only intending to run a 
HTTP service and DNS service is it fine the way it is?

Also, I intend to keep the script stateless not wanting to use conntrack 
at all.

Thanks
Alex


#!/bin/bash

/sbin/iptables -F
/sbin/iptables -X

/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT ACCEPT

#Accept SSH
/sbin/iptables -A INPUT -p tcp -m tcp -s 204.199.62.74 --dport 22 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 1000:65535 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT
/sbin/iptables -A INPUT -p udp --dport 53 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 53 -j ACCEPT


--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
&lt;/pre&gt;</description>
    <dc:creator>Alex Flex</dc:creator>
    <dc:date>2013-06-15T23:38:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46092">
    <title>Poll on netfilter_queue filedescriptor doesn't work.</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46092</link>
    <description>&lt;pre&gt;Hi,

Poll on the file descriptor returned by nfq_fd() doesn't work. I am
polling for the following events
POLLIN | POLLPRI | POLLERR | POLLHUP.

But none of these events are set when there is a packet on the netfilter_queue.

Can someone please let me know the best way to poll or missing things
on the nfq file descriptor

--
Thanks,
Raju.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>LakshmiPathi Raju Poranki</dc:creator>
    <dc:date>2013-06-13T16:54:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46091">
    <title>Re: xt_SECMARK: unable to map security context 'httpcontext (error)</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46091</link>
    <description>&lt;pre&gt;Hi Kevin,

On 06/03/2013 07:12 PM, Kevin Wilson wrote:

IIRC, you need to specify the complete SELinux context, e.g.

system_u:object_r:user_home_t

HTH,
daniel
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Daniel Wagner</dc:creator>
    <dc:date>2013-06-13T15:13:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46090">
    <title>Re: Simple libipset program fails to link on Ubuntu 12.04 (precise)</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46090</link>
    <description>&lt;pre&gt;

This compiles cleanly with a more recent ipset library.
 

Yes, you can install a custom library for example in /usr/local and use 
it. The userspace ipset library and program is independent from the kernel 
part modules: they'll negotiate the best common functionality and will use 
that.
 

The function ipset_port_usage was missing from the library, it was fixed 
in 6.12. You can find the patch in git, but it's easier to use a more 
recent package and the library from it.

Best regards,
Jozsef
-
E-mail  : kadlec&amp;lt; at &amp;gt;blackhole.kfki.hu, kadlecsik.jozsef&amp;lt; at &amp;gt;wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Jozsef Kadlecsik</dc:creator>
    <dc:date>2013-06-11T19:13:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46088">
    <title>Simple libipset program fails to link on Ubuntu 12.04 (precise)</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46088</link>
    <description>&lt;pre&gt;Greetings,

I am trying to write a very simple ipset program using libipset on
Ubuntu 12.04 (precise).  I have libipset-dev installed and the
following program fails to link.

#include &amp;lt;assert.h&amp;gt;     /* assert */
#include &amp;lt;ctype.h&amp;gt;      /* isspace */
#include &amp;lt;errno.h&amp;gt;      /* errno */
#include &amp;lt;stdarg.h&amp;gt;     /* va_* */
#include &amp;lt;stdbool.h&amp;gt;      /* bool */
#include &amp;lt;stdio.h&amp;gt;      /* fprintf, fgets */
#include &amp;lt;stdlib.h&amp;gt;     /* exit */
#include &amp;lt;string.h&amp;gt;     /* str* */

#include &amp;lt;libipset/data.h&amp;gt;    /* enum ipset_data */
#include &amp;lt;libipset/parse.h&amp;gt;   /* ipset_parse_* */
#include &amp;lt;libipset/session.h&amp;gt;   /* ipset_session_* */
#include &amp;lt;libipset/types.h&amp;gt;   /* struct ipset_type */
#include &amp;lt;libipset/ui.h&amp;gt;    /* core options, commands */
#include &amp;lt;libipset/utils.h&amp;gt;   /* STREQ */

int main(int argc, char *argv[]) {

  struct ipset_session *session;

  session = ipset_session_init(printf);
  if (session == NULL) {
    fprintf(stderr, "Cannot initialize ipset session, aborting.\n");
    return -1;
  }

  ipset_sessio&lt;/pre&gt;</description>
    <dc:creator>Dan Cook</dc:creator>
    <dc:date>2013-06-10T21:15:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46085">
    <title>error during nfq_bind_pf() for PF_INET6</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46085</link>
    <description>&lt;pre&gt;Hi,

Not able to bind nfnetlink_queue for ipv6. The following is the error message.

binding nfnetlink_queue as nf_queue handler for AF_INET6 family.
error during nfq_bind_pf()

Can someone please guide me to resolve the issue.


I have these modules

nfnetlink_queue        17149  0
nfnetlink              12906  1 nfnetlink_queue

--
Thanks,
Raju.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>LakshmiPathi Raju Poranki</dc:creator>
    <dc:date>2013-06-07T16:01:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46084">
    <title>Re: [patch] ipvs: info leak in __ip_vs_get_dest_entries()</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46084</link>
    <description>&lt;pre&gt;
This is a static checker fix.  To me it seems like it's obviously a
real info leak.

I'm not certain of the impact though.  CLONE_NEWNET requires
CAP_SYS_ADMIN but on the other hand people are making virtualization
products where they give everyone their own namespace with admin
privileges.

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Dan Carpenter</dc:creator>
    <dc:date>2013-06-07T08:33:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46083">
    <title>Re: Locally transmitted Multicast packets are being looped back, even if IP_MULTICAST_LOOP option is set to zero</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46083</link>
    <description>&lt;pre&gt;
Yes, it was added in 2.6.36

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7b2ff18ee7b0ec4bc3162f821e221781aaca48bd



--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Eric Dumazet</dc:creator>
    <dc:date>2013-06-05T14:20:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46080">
    <title>Locally transmitted Multicast packets are being looped back, even if IP_MULTICAST_LOOP option is set to zero</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46080</link>
    <description>&lt;pre&gt;Hi,
   I am Vijay Tandeker working in TejasNetworks Bangalore, which works 
in a telecommunication domain. I have one query regarding 
IP_MULTICAST_LOOP option.

My configuration:
Kernel version: 2.6.32
One OSPF routing protocol deamon is running in my system. It has opened 
one raw socket with
- IP_HDRINCL option set to 1
- IP_MULTICAST_LOOP option set to 0

IP fragmentation logic is implemented in my application. Means if OSPF 
tries to send any packet which exceeds MTU of the transmitting 
interface, it fragments it and gives to the kernel using sendmsg(). In 
my case, I am getting all my fragmented packets back to the application 
(which should not happen if IP_MULTICAST_LOOP option is set to zero).

Following are my observations:
1) In ip_mc_output() function inside "net/ipv4/ip_output.c" file:


/*
  *  Multicasts are looped back for other local users
  */

     if (rt-&amp;gt;rt_flags&amp;amp;RTCF_MULTICAST) {
         if ((!sk || inet_sk(sk)-&amp;gt;mc_loop)
#ifdef CONFIG_IP_MROUTE
                 /* Small optimization: &lt;/pre&gt;</description>
    <dc:creator>Vijay Tandeker</dc:creator>
    <dc:date>2013-06-05T10:47:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46079">
    <title>Re: Filtering Broadcasted UDP Packets on a Specific Bridged Interface</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46079</link>
    <description>&lt;pre&gt;Hello,

Dan Osawa a écrit :

Weird message. I wonder how bridged traffic could ever reach the OUTPUT
chain...


Yes. At the time iptables handles the packet, the output port is not
known yet.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Pascal Hambourg</dc:creator>
    <dc:date>2013-06-04T07:35:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46076">
    <title>xt_SECMARK: unable to map security context 'httpcontext (error)</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46076</link>
    <description>&lt;pre&gt;Hi,
I am trying in Ubuntu 13.04 to run this:

 -
modprobe xt_SECMARK
than:
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j SECMARK --selctx httpconte

And I get:
iptables: No chain/target/match by that name.

syslog says:
Jun  3 20:09:48 amd kernel: [ 3269.413962] xt_SECMARK: unable to map
security context 'httpcontext

what should I do ?

Kernel:
3.8.0-19-generic
iptables v1.4.12


regards,
Kevin
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Kevin Wilson</dc:creator>
    <dc:date>2013-06-03T17:12:53</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46074">
    <title>Filtering Broadcasted UDP Packets on a Specific Bridged Interface</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46074</link>
    <description>&lt;pre&gt;My PC has two network interfaces (eth0 &amp;amp; usb0) that are bridged. There
is a service on my PC that broadcasts UDP packets on a specific port
(7000). I would like to prevent these UDP packets from leaving my PC
via the eth0 interface, only allowing packets to exit via the usb0
interface.

I tried to do this by adding an iptable rule to the filter table's
OUTPUT chain (see below).

iptables -F

iptables -A OUTPUT -p udp --dport 7000 -m physdev --physdev-out eth0 -j DROP

Doing the above results in an error: *xt_physdev: using --physdev-out
in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic
is not supported anymore.*

So i tried the following:

iptables -F

iptables -A OUTPUT -p udp --dport 7000 -m physdev --physdev-out eth0
--physdev-is-bridged -j DROP

The above doesn't fail, but also doesn't suppress the packets.

Any suggestions?  Am I way off in thinking that IP tables can do this?
 Do I need to use etables instead?


thanks in advance,

Dan
--
To unsubscribe from this list: send the line&lt;/pre&gt;</description>
    <dc:creator>Dan Osawa</dc:creator>
    <dc:date>2013-06-03T00:29:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46073">
    <title>[No subject]</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46073</link>
    <description>&lt;pre&gt;http://alexanderlattagardens.co.uk/gdjxy/mevffylewqfsthznvp.hfkvrosf
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Giovane</dc:creator>
    <dc:date>2013-06-02T11:27:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46071">
    <title>netfilter routing/snat latency</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46071</link>
    <description>&lt;pre&gt;Hello,

Are there any figures about netfilter routing/nating latency on any modern
HW (QORIQ from freescale or Intel Core iX) ?

Thanks in advance

François
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>François Legal</dc:creator>
    <dc:date>2013-05-29T14:00:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46069">
    <title>Re: Strange behavior with ipset not matching on public range</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46069</link>
    <description>&lt;pre&gt;

commit ef5b6e127761667f78d99b7510a3876077fe9abe
Author: Florian Westphal &amp;lt;fw&amp;lt; at &amp;gt;strlen.de&amp;gt;
Date:   Sun Jun 17 09:56:46 2012 +0000

    netfilter: ipset: fix interface comparision in hash-netiface sets
    
    ifname_compare() assumes that skb-&amp;gt;dev is zero-padded,
    e.g 'eth1\0\0\0\0\0...'. This isn't always the case. e1000 driver does
    
    strncpy(netdev-&amp;gt;name, pci_name(pdev), sizeof(netdev-&amp;gt;name) - 1);
    
    in e1000_probe(), so once device is registered dev-&amp;gt;name memory contains
    'eth1\0:0:3\0\0\0' (or something like that), which makes eth1 compare
    fail.
    
    Use plain strcmp() instead.
    
    Signed-off-by: Florian Westphal &amp;lt;fw&amp;lt; at &amp;gt;strlen.de&amp;gt;
    Signed-off-by: Pablo Neira Ayuso &amp;lt;pablo&amp;lt; at &amp;gt;netfilter.org&amp;gt;

Best regards,
Jozsef
-
E-mail  : kadlec&amp;lt; at &amp;gt;blackhole.kfki.hu, kadlecsik.jozsef&amp;lt; at &amp;gt;wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary
--
To unsubscribe fro&lt;/pre&gt;</description>
    <dc:creator>Jozsef Kadlecsik</dc:creator>
    <dc:date>2013-05-28T13:35:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46068">
    <title>Re: Strange behavior with ipset not matching on public range</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/46068</link>
    <description>&lt;pre&gt;
And by the why is their a way to trace this issue? I mean it would be
useful in the bug report to show that something is going the wrong way.

--
Jimmy



--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Jimmy Thrasibule</dc:creator>
    <dc:date>2013-05-28T13:33:55</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.security.firewalls.netfilter.general">
    <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.firewalls.netfilter.general</link>
  </textinput>
</rdf:RDF>
