<?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/44499"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44498"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44497"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44496"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44495"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44494"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44493"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44492"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44490"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44489"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44488"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44487"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44484"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44483"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44482"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44481"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44480"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44479"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44477"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44476"/>
      </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/44499">
    <title>Re: connlimit and rejected connections staying in conntrack table</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44499</link>
    <description>&lt;pre&gt;

Odd, because I could reproduce what you described (with as few as 3..5 
connections).
--
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>Jan Engelhardt</dc:creator>
    <dc:date>2012-05-25T09:53:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44498">
    <title>Re: connlimit and rejected connections staying in conntrack table</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44498</link>
    <description>&lt;pre&gt;
Finally figured this out - those conntrack entries weren't, in fact related to connlimit rejecting connections. The SYNs were unreplied because SYN flood protection kicked in when I tested by throwing lots of connections at it. I have enabled SYN cookies and things are now working as expected.

Eric--
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 Petit</dc:creator>
    <dc:date>2012-05-25T09:50:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44497">
    <title>Re: Nix-AW: AW: How to mark packet by reqid?</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44497</link>
    <description>&lt;pre&gt;
On Thursday 2012-05-17 22:15, Steffen Heil (Mailinglisten) wrote:

Sigh. Then I don't know, but it ought to be enabled somehow at runtime,
this awesome dynamic printk thing. (provided it's compiled)



Is modprobe broken on your system? It is loaded automatically
(try_then_request_module from the kernel).


So, kernel without mangle table or without xt_esp or without MARK.
Pretty easy:
modprobe -q xt_esp
ls -dl /sys/module/xt_esp
etc.

--
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>Jan Engelhardt</dc:creator>
    <dc:date>2012-05-25T09:43:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44496">
    <title>xfrm decode / SA matching</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44496</link>
    <description>&lt;pre&gt;Hi

I have several SAs with the same networks and gateways on both sides but
different xmarks (1 vs 2) and those work correctly.

Therefor I need iptable rules like the following (in raw/PREROUTING):

-p esp -m esp --espspi 0xc270c557 -j MARK --set-mark 1
-p esp -m esp --espspi 0xcaa7e5c8 -j MARK --set-mark 2

Then netfilter selects the correct SA.

However, as the esp packets contain the spi value, I also expected them to
work correctly if they have the same xmark (both 1):

-p esp -m esp --espspi 0xc270c557 -j MARK --set-mark 1
-p esp -m esp --espspi 0xcaa7e5c8 -j MARK --set-mark 1

Yet, this does not work.
I get the feeling that the selection of the correct SA is not based on the
spi but on the ip and xmark only.

This this true?
If so, why? Isn't the SPI especially there for that reason?

Can this be archived somehow?

Best regards,
  Steffen


&lt;/pre&gt;</description>
    <dc:creator>Steffen Heil (Mailinglisten</dc:creator>
    <dc:date>2012-05-25T09:01:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44495">
    <title>Re: 'swap table' feature</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44495</link>
    <description>&lt;pre&gt;
Well, yes, I've heard of, and have used, iptables-restore. But I don't recall 
ever seeing mention of such a feature or how it works. Now that I'm aware of 
it, I's'll have to investigate.

Thanks,
N
--
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>2012-05-23T22:03:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44494">
    <title>Re: 'swap table' feature</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44494</link>
    <description>&lt;pre&gt;


What, never heard of iptables-restore? Atomic replace has been in 
iptables since a long long time.
--
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>Jan Engelhardt</dc:creator>
    <dc:date>2012-05-23T21:53:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44493">
    <title>'swap table' feature</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44493</link>
    <description>&lt;pre&gt;I knew I'd eventually remember why I subscribed to this list....

While working on enhancing my firewall, it occurred to me that it'd be real 
nice to have a 'swap chain' feature in iptables that is equivalent to the 
'swap set' feature in ipset.

Such a feature would minimize the amount of time that rules are unavailable 
when adding, changing or deleting them. At present, all the rules in the chain 
being modified are deleted, then the new rules are added. So there is a period 
of time, albeit brief, that rules are not available in that chain.

Were there a 'swap chain' command, one could build a new chain of the changed 
rules, swap the new and old chains, then flush and delete the new (now old) 
chain. This would all but guarantee that no packets 'slip by' (are 
overlooked).

Thanks,
N
--
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>2012-05-23T21:25:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44492">
    <title>connlimit and rejected connections staying in conntrack table</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44492</link>
    <description>&lt;pre&gt;Hello,

I am trying to limit the total number of concurrent connections that may be established on a given port. I need additional connection attempts to be explicitly rejected, so I went for something like:

iptables -P INPUT DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 512 --connlimit-mask 0 -j REJECT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

My problem is, when the limit is reached and new connections are rejected, those stay in the conntrack table in a SYN_SENT / UNREPLIED state, and are only cleaned up after 120 seconds (ip_conntrack_tcp_timeout_syn_sent). As such, they are accounted for as active connections by connlimit, and new connections keep being rejected even though the number of established connections is, in fact, lower than the limit that I set. If connections keep coming in at a fast pace, it may just never accept a connection again. I've tried "--reject-with tcp-reset" and the behavior was the s&lt;/pre&gt;</description>
    <dc:creator>Eric Petit</dc:creator>
    <dc:date>2012-05-23T15:29:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44490">
    <title>Packet dropped without reason</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44490</link>
    <description>&lt;pre&gt;Hi

I follow a ping through my gateway with log-commands at the end of each
chain:


Receiving a echo request on eth1 and forwarding it encrypted to a gateway on
eth0 works as expected:
(Although nat_OUTPUT is missing between step 9 and 10 and nat_POSTROUTING is
missing after step 11 compared to http://inai.de/images/nf-packet-flow.png,
but I expect this to be correct, as I do not use nat.)

1. May 19 18:58:11 vpn-a kernel: [ 4396.217687] raw_PREROUTING: IN=eth1 OUT=
MAC=00:16:3e:0f:01:01:00:16:3e:0f:03:00:08:00 SRC=10.1.1.2 DST=10.2.1.2
LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41230
SEQ=1

2. May 19 18:58:11 vpn-a kernel: [ 4396.217702] mangle_PREROUTING: IN=eth1
OUT= MAC=00:16:3e:0f:01:01:00:16:3e:0f:03:00:08:00 SRC=10.1.1.2 DST=10.2.1.2
LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41230
SEQ=1 MARK=0x1

3. May 19 18:58:11 vpn-a kernel: [ 4396.217710] nat_PREROUTING: IN=eth1 OUT=
MAC=00:16:3e:0f:01:01:00:16:3e:0f:03:00:08:00 SRC=10.1.1.2 DST=10.2.1.2
LEN=8&lt;/pre&gt;</description>
    <dc:creator>Steffen Heil (Mailinglisten</dc:creator>
    <dc:date>2012-05-19T19:12:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44489">
    <title>RE: AW: How to mark packet by reqid?</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44489</link>
    <description>&lt;pre&gt;Hi

First of all, sorry for the previous posts. After taking some time off and
giving this a fresh look, I realized I did not only do some copy and paste
errors for these mails, but also my focus for the correct matching
conditions was that fixed, that I totally overlooked having "-D" instead of
"-A" in some of my commands. Obviously they didn't work...

My sincere apologies for that.

Now, I got the following working:

iptables -t mangle -A PREROUTING --proto esp -m esp --espspi 0xc522b7f3 -j
MARK --set-mark 1

I tried to transform that to 

iptables -t mangle -A PREROUTING --proto esp -m policy --spi 0xc522b7f3 -j
MARK --dir in --set-mark 1

But then it does not work anymore. Is there any fundamental difference
between those conditions that I do not understand?
Note: My original target was to use reqid instead of spi, because I can fix
the reqid and the filewall rules should be independent of IKE...

Regards,
  Steffen

&lt;/pre&gt;</description>
    <dc:creator>Steffen Heil (Mailinglisten</dc:creator>
    <dc:date>2012-05-19T11:33:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44488">
    <title>ebtables queue/nfqueue target</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44488</link>
    <description>&lt;pre&gt;hi guys,

has anyone ever tried queue/nfqueue target in ebtables? I'm not sure
if it has been implemented in ebtables, though it has in iptables. Or
does community plan to implement it in the future?

thank you very much

BRs
jerry
--
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>JieYue Ma</dc:creator>
    <dc:date>2012-05-18T16:44:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44487">
    <title>Re: High ksoftirqd CPU load, high latency [somewhat SOLVED]</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44487</link>
    <description>&lt;pre&gt;
Hi Robe
Your problem looks insteresting. I would like how reacreate your problem and
test further.

Do you have any methods?


--
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>Vairavan</dc:creator>
    <dc:date>2012-05-18T14:51:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44484">
    <title>RE: AW: How to mark packet by reqid?</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44484</link>
    <description>&lt;pre&gt;Another fact:

I added a logging rule and I got logged:

May 18 09:27:00 vpn-a kernel: [49503.963182] mangle_PREROUTING: IN=eth0 OUT=
MAC=00:16:3e:0f:01:00:00:16:3e:0f:02:00:08:00 SRC=10.5.0.2 DST=10.5.0.1
LEN=152 TOS=0x00 PREC=0x00 TTL=64 ID=56019 PROTO=ESP SPI=0xc89f8130

My mange / POSTROUTING rules:

-s 10.1.1.0/24 -d 10.2.1.0/24 -j MARK --set-xmark 0x1/0xffffffff
-p esp -m policy --dir in --pol ipsec --spi 0xc89f8130 -j MARK --set-xmark
0x1/0xffffffff
-p esp -m policy --dir in --pol ipsec --reqid 1 -j MARK --set-xmark
0x1/0xffffffff
-j LOG --log-prefix "mangle_PREROUTING: "

Yet the packet did not get marked...
I start to believe this is a bug.

Regards,
  Steffen



&lt;/pre&gt;</description>
    <dc:creator>Steffen Heil (Mailinglisten</dc:creator>
    <dc:date>2012-05-18T09:35:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44483">
    <title>[ANNOUNCE] libnetfilter_conntrack 1.0.1 release</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44483</link>
    <description>&lt;pre&gt;Hi!

The Netfilter project proudly presents:

        libnetfilter_conntrack 1.0.1

libnetfilter_conntrack is a userspace library providing a programming
interface (API) to the in-kernel connection tracking state table.
This library is currently used by conntrack-tools among many other
applications.

This release includes important improvements for the expectation
support.

See ChangeLog that comes attached to this email for more details.

You can download it from:

http://www.netfilter.org/projects/libnetfilter_conntrack/downloads.html
ftp://ftp.netfilter.org/pub/libnetfilter_conntrack/

Have fun!
Kelvie Wong (1):
      expect: support NFCT_Q_CREATE_UPDATE in nfexp_query

Pablo Neira Ayuso (15):
      expect: add XML support for nfexp_snprintf()
      expect: add class support
      expect: add NAT support
      expect: add expectfn support
      expect: CTA_EXPECT_HELP_NAME must be NULL-terminated
      expect: fix comparison of expectation class and flags
      expect: fix missing whitespace after expecta&lt;/pre&gt;</description>
    <dc:creator>Pablo Neira Ayuso</dc:creator>
    <dc:date>2012-05-18T00:35:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44482">
    <title>RE: AW: How to mark packet by reqid?</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44482</link>
    <description>&lt;pre&gt;BTW, if that helps, here is some information about my systems.
(Ubuntu 12.04 LTS Precise Pangolin, currently virtual, 64bit, fully
updated.)


root&amp;lt; at &amp;gt;vpn-a:~# iptables --version
iptables v1.4.12


root&amp;lt; at &amp;gt;vpn-a:~# uname -a
Linux vpn-a 3.2.0-24-virtual #37-Ubuntu SMP Wed Apr 25 10:17:19 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux


root&amp;lt; at &amp;gt;vpn-a:~# lsmod
Module                  Size  Used by
xt_policy              12670  1
xt_esp                 12529  0
iptable_mangle         12734  1
xt_mark                12563  2
ip_tables              27473  1 iptable_mangle
x_tables               29846  5
xt_policy,xt_esp,iptable_mangle,xt_mark,ip_tables
authenc                17582  2
xfrm6_mode_tunnel      12639  2
xfrm4_mode_tunnel      12639  4
xfrm_user              31825  2
xfrm4_tunnel           12779  0
tunnel4                13213  1 xfrm4_tunnel
ipcomp                 12673  0
xfrm_ipcomp            13556  1 ipcomp
esp4                   17061  2
ah4                    12885  0
deflate                12617  0
zlib_deflate&lt;/pre&gt;</description>
    <dc:creator>Steffen Heil (Mailinglisten</dc:creator>
    <dc:date>2012-05-17T20:39:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44481">
    <title>AW: AW: How to mark packet by reqid?</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44481</link>
    <description>&lt;pre&gt;Hi again,


Lots of experiments later, but still no luck....


it.

I did. And I tried 
# echo "7 7 7 7" &amp;gt; /proc/sys/kernel/printk

Nothing appears on `dmesg`.
Also I noticed that xt_esp was not loaded automatically. I had to load it
using `insmod`. Still no output.
But note, that I could not use -m esp --espspi either, see below.



-m esp --espspi XXXXX
Or
-m polixy --spi XXXXX --dir in

The later does not match, but I cannot even get the former one to be
accepted:

# iptables -t mangle -D PREROUTING -p esp -m esp --espspi 0xcde0e1ca -j MARK
--set-mark 1
iptables: No chain/target/match by that name.

# iptables -t mangle -D PREROUTING -p esp --espspi 0xcde0e1ca -j MARK
--set-mark 1
iptables: No chain/target/match by that name.

# iptables -t mangle -D PREROUTING -m esp --espspi 0xcde0e1ca -j MARK
--set-mark 1
iptables: No chain/target/match by that name.

Is there a way to find out what's wrong here?


value)

--espspi does not work at all - iptables complains, see above.
Also, I tried  -m polixy --spi XXX&lt;/pre&gt;</description>
    <dc:creator>Steffen Heil (Mailinglisten</dc:creator>
    <dc:date>2012-05-17T20:15:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44480">
    <title>SNAT/MASQ on a single subnet</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44480</link>
    <description>&lt;pre&gt;Hi I'm trying to work out what I guess might not be possible
with iptables or is simple and I"m just missing something

I have 3 devices on the same subnet

192.168.0.1 ADSL Router
192.168.0.240 Linux Server
192.168.0.100 Windows PC

The Linux server has no rules and ACCEPT on all

What would the minimum necessary rule(s) to get the Linux Server
to forward (with SNAT or MASQUERADE) packets through the Router
from 192.168.0.100 and also send the replies back?

The Linux Server has 192.168.0.1 as it's gateway and also
has ip forwarding enabled

I set the gateway on the windows PC to 192.168.0.240

I tried a few simple single rules and failed.
(Just the single rule and deleted it after)
2 examples were:

iptables -t nat -A POSTROUTING -o br0 -s 192.168.0.0/24 ! -d
192.168.0.0/24 -j SNAT --to 192.168.0.240

iptables -t nat -A POSTROUTING -o br0 -s 192.168.0.0/24 -j SNAT --to
192.168.0.240

Single ping shows:
192.168.0.100 -&amp;gt; 74.125.237.113
192.168.0.240 -&amp;gt; 74.125.237.113
74.125.237.113 -&amp;gt; 192.168.0.240

but no "&lt;/pre&gt;</description>
    <dc:creator>Andrew</dc:creator>
    <dc:date>2012-05-17T16:18:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44479">
    <title>iptable stop hung</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44479</link>
    <description>&lt;pre&gt;Hi,

"iptable stop" got hung in the server, so I killed that process. But 
still there is a modprobe process running there, that I can't kill.

oot     13834 99.8  0.0   3884   596 ?        R    11:15 132:39 
/sbin/modprobe -q -r ipt_state ip_nat_ftp iptable_nat xt_NOTRACK 
ip_conntrack_ftp ip_conntrack_netbios_ns xt_connlimit ip_conntrack 
ipt_recent

This is what I can see in dmesg

http://pastebin.com/BxEsyByC

--Unni
--
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>Unni</dc:creator>
    <dc:date>2012-05-17T13:30:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44477">
    <title>Re: Need info about how to run nfqnl_test.c !!</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44477</link>
    <description>&lt;pre&gt;Thanks a lot Wento !! for your time and information provided




On Wed, May 16, 2012 at 4:02 PM, Wentao Shang &amp;lt;wentaoshang&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:



&lt;/pre&gt;</description>
    <dc:creator>Sudheer</dc:creator>
    <dc:date>2012-05-16T10:38:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44476">
    <title>Re: Need info about how to run nfqnl_test.c !!</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44476</link>
    <description>&lt;pre&gt;You may call nfq_create_queue() several times and specify each queue
with different number (the 2nd param in the function) and different
callback routine. However, I'm not sure how the incoming packets are
delivered to different queues. Maybe you should use select() or poll()
here.

Wentao

2012/5/16 Sudheer &amp;lt;sudheer.d&amp;lt; at &amp;gt;oneconvergence.com&amp;gt;:



&lt;/pre&gt;</description>
    <dc:creator>Wentao Shang</dc:creator>
    <dc:date>2012-05-16T10:32:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44475">
    <title>ulog2 final release</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44475</link>
    <description>&lt;pre&gt;Hi,

Is there any plans to release the version 2 of ulog ?

It would be nice it is included in Wheezy version of Debian, which
must be frozen soon.

Thanks !
Benoît.
--
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>SPONEM, Benoît</dc:creator>
    <dc:date>2012-05-16T09:20:05</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>

