Linux TCP/IP Netfilter

• Thread Index

• [patch v5 06/12] IPVS: ip_vs_{un,}bind_scheduler NULL arguments
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v5 05/12] IPVS: Allow null argument to ip_vs_scheduler_put()
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v5 04/12] IPVS: Add struct ip_vs_conn_param
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v5 03/12] IPVS: compact ip_vs_sched_persist()
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v5 02/12] netfilter: nf_conntrack_sip: Add callid parser
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v5 01/12] netfilter: nf_conntrack_sip: Allow ct_sip_get_header() to be called with a null ct argument
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v5 00/12] IPVS: SIP Persistence Engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: [patch v4 10/12] IPVS: Allow configuration of persistence engines
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: [patch v4 00/12] IPVS: SIP Persistence Engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: ipporthash, ipportiphash, ipportnethash problems
  • From: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
• [patch v4 12/12] IPVS: sip persistence engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v4 11/12] IPVS: Fallback if persistence engine fails
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v4 10/12] IPVS: Allow configuration of persistence engines
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v4 09/12] IPVS: management of persistence engine modules
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v4 08/12] IPVS: Add persistence engine data to /proc/net/ip_vs_conn
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v4 07/12] IPVS: Add struct ip_vs_pe
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v4 06/12] IPVS: ip_vs_{un,}bind_scheduler NULL arguments
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v4 05/12] IPVS: Allow null argument to ip_vs_scheduler_put()
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v4 04/12] IPVS: Add struct ip_vs_conn_param
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v4 03/12] IPVS: compact ip_vs_sched_persist()
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v4 02/12] netfilter: nf_conntrack_sip: Add callid parser
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v4 01/12] netfilter: nf_conntrack_sip: Allow ct_sip_get_header() to be called with a null ct argument
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v4 00/12] IPVS: SIP Persistence Engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: ipporthash, ipportiphash, ipportnethash problems
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: ipporthash, ipportiphash, ipportnethash problems
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: IP set and match skiping
  • From: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
• Re: ipporthash, ipportiphash, ipportnethash problems
  • From: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
• Re: ipporthash, ipportiphash, ipportnethash problems
  • From: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
• IP set and match skiping
  • From: Daniel Dehennin <daniel.dehennin@xxxxxxxxxxxx>
• Re: [patch v3 00/12] IPVS: SIP Persistence Engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: nfqnl_test exits abnormally while monitoring some TCP packets.
  • From: Mistick Levi <gmistick@xxxxxxxxx>
• Re: netfilter and IPsec?
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: netfilter and IPsec?
  • From: Christoph Anton Mitterer <christoph.anton.mitterer@xxxxxxxxxxxxxxxxxxxxxx>
• Re: ipporthash, ipportiphash, ipportnethash problems
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: ipporthash, ipportiphash, ipportnethash problems
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: netfilter and IPsec?
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: ipporthash, ipportiphash, ipportnethash problems
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: ipporthash, ipportiphash, ipportnethash problems
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: ipporthash, ipportiphash, ipportnethash problems
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: ipporthash, ipportiphash, ipportnethash problems
  • From: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
• netfilter and IPsec?
  • From: Christoph Anton Mitterer <christoph.anton.mitterer@xxxxxxxxxxxxxxxxxxxxxx>
• Re: ipporthash, ipportiphash, ipportnethash problems
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: [patch v3 00/12] IPVS: SIP Persistence Engine
  • From: Julian Anastasov <ja@xxxxxx>
• Re: [patch v2 03/12] [PATCH 03/12] IPVS: compact ip_vs_sched_persist()
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: [patch v2 03/12] [PATCH 03/12] IPVS: compact ip_vs_sched_persist()
  • From: Julian Anastasov <ja@xxxxxx>
• [patch v3 12/12] IPVS: sip persistence engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v3 11/12] IPVS: Fallback if persistence engine fails
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v3 10/12] IPVS: Allow configuration of persistence engines
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v3 09/12] IPVS: management of persistence engine modules
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v3 08/12] IPVS: Add persistence engine data to /proc/net/ip_vs_conn
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v3 07/12] IPVS: Add struct ip_vs_pe
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v3 06/12] IPVS: ip_vs_{un,}bind_scheduler NULL arguments
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v3 05/12] IPVS: Allow null argument to ip_vs_scheduler_put()
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v3 04/12] IPVS: Add struct ip_vs_conn_param
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v3 03/12] IPVS: compact ip_vs_sched_persist()
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v3 02/12] netfilter: nf_conntrack_sip: Add callid parser
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v3 01/12] netfilter: nf_conntrack_sip: Allow ct_sip_get_header() to be called with a null ct argument
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v3 00/12] IPVS: SIP Persistence Engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: [patch v2 03/12] [PATCH 03/12] IPVS: compact ip_vs_sched_persist()
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: [patch v2 08/12] [PATCH 08/12] IPVS: Add persistence engine data to /proc/net/ip_vs_conn
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: [patch v2 07/12] [PATCH 07/12] IPVS: Add struct ip_vs_pe
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: [patch v2 04/12] [PATCH 04/12] IPVS: Add struct ip_vs_conn_param
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: [patch v2 04/12] [PATCH 04/12] IPVS: Add struct ip_vs_conn_param
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: string and u32 modules
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: [patch v2 03/12] [PATCH 03/12] IPVS: compact ip_vs_sched_persist()
  • From: Julian Anastasov <ja@xxxxxx>
• Re: fwmark in the OUTPUT chain
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: [patch v2 08/12] [PATCH 08/12] IPVS: Add persistence engine data to /proc/net/ip_vs_conn
  • From: Julian Anastasov <ja@xxxxxx>
• Re: [patch v2 07/12] [PATCH 07/12] IPVS: Add struct ip_vs_pe
  • From: Julian Anastasov <ja@xxxxxx>
• Re: ipporthash, ipportiphash, ipportnethash problems
  • From: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
• [ANNOUNCE] ipset-4.4 released
  • From: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
• Re: [patch v2 04/12] [PATCH 04/12] IPVS: Add struct ip_vs_conn_param
  • From: Julian Anastasov <ja@xxxxxx>
• Re: [patch v2 00/12] IPVS: SIP Persistence Engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v2 12/12] [PATCH 12/12] IPVS: sip persistence engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v2 11/12] [PATCH 11/12] IPVS: Fallback if persistence engine fails
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v2 10/12] [PATCH 10/12] IPVS: Allow configuration of persistence engines
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v2 09/12] [PATCH 09/12] IPVS: management of persistence engine modules
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v2 08/12] [PATCH 08/12] IPVS: Add persistence engine data to /proc/net/ip_vs_conn
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v2 07/12] [PATCH 07/12] IPVS: Add struct ip_vs_pe
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v2 06/12] [PATCH 06/12] IPVS: ip_vs_{un,}bind_scheduler NULL arguments
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v2 05/12] [PATCH 05/12] IPVS: Allow null argument to ip_vs_scheduler_put()
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v2 04/12] [PATCH 04/12] IPVS: Add struct ip_vs_conn_param
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v2 03/12] [PATCH 03/12] IPVS: compact ip_vs_sched_persist()
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v2 2/2] [PATCH 2/2] Add support for persistence engines.
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v2 02/12] [PATCH 02/12] netfilter: nf_conntrack_sip: Add callid parser
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v2 01/12] [PATCH 01/12] netfilter: nf_conntrack_sip: Allow ct_sip_get_header() to be called with a null ct argument
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v2 1/2] [PATCH 1/2] Slightly simplify options conflicts logic
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v2 0/2] [patch v1 0/2] ipvsadm: SIP Persistence Engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v2 00/12] IPVS: SIP Persistence Engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: nfqnl_test exits abnormally while monitoring some TCP packets.
  • From: Shihwei Li <lishihwei@xxxxxxxxx>
• Re: ipporthash, ipportiphash, ipportnethash problems
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: nfqnl_test exits abnormally while monitoring some TCP packets.
  • From: Mistick Levi <gmistick@xxxxxxxxx>
• Re: ipporthash, ipportiphash, ipportnethash problems
  • From: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
• ipporthash, ipportiphash, ipportnethash problems
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: fwmark in the OUTPUT chain
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: nfqnl_test exits abnormally while monitoring some TCP packets.
  • From: Shihwei Li <lishihwei@xxxxxxxxx>
• nfqnl_test exits abnormally while monitoring some TCP packets.
  • From: Shihwei Li <lishihwei@xxxxxxxxx>
• Problem with buffering packets
  • From: David <netfilter@xxxxxxxxxxxxxxxx>
• fwmark in the OUTPUT chain
  • From: Christopher Piggott <cpiggott@xxxxxxxxx>
• Re: macipmap (ipset) matching
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: macipmap (ipset) matching
  • From: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
• macipmap (ipset) matching
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: [PATCH 3/6] secmark: export binary yes/no rather than kernel internal secid
  • From: Casey Schaufler <casey@xxxxxxxxxxxxxxxx>
• Re: [PATCH 3/6] secmark: export binary yes/no rather than kernel internal secid
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: [PATCH 3/6] secmark: export binary yes/no rather than kernel internal secid
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: [PATCH 3/6] secmark: export binary yes/no rather than kernel internal secid
  • From: James Morris <jmorris@xxxxxxxxx>
• Re: [PATCH 3/6] secmark: export binary yes/no rather than kernel internal secid
  • From: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
• Re: [PATCH 3/6] secmark: export binary yes/no rather than kernel internal secid
  • From: Paul Moore <paul.moore@xxxxxx>
• Re: [PATCH 3/6] secmark: export binary yes/no rather than kernel internal secid
  • From: Eric Paris <eparis@xxxxxxxxxx>
• Re: [PATCH 3/6] secmark: export binary yes/no rather than kernel internal secid
  • From: Paul Moore <paul.moore@xxxxxx>
• Re: [PATCH 2/6] secmark: make secmark object handling generic
  • From: Eric Paris <eparis@xxxxxxxxxx>
• Re: [PATCH 3/6] secmark: export binary yes/no rather than kernel internal secid
  • From: Eric Paris <eparis@xxxxxxxxxx>
• Re: [PATCH 5/6] conntrack: export lsm context rather than internal secid via netlink
  • From: Eric Paris <eparis@xxxxxxxxxx>
• Re: [PATCH 3/6] secmark: export binary yes/no rather than kernel internal secid
  • From: Eric Paris <eparis@xxxxxxxxxx>
• Re: [PATCH 4/6] security: secid_to_secctx returns len when data is NULL
  • From: Casey Schaufler <casey@xxxxxxxxxxxxxxxx>
• Re: [PATCH 5/6] conntrack: export lsm context rather than internal secid via netlink
  • From: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
• Re: redirecting connections to userspace
  • From: rhn <vamali.rhn@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 3/6] secmark: export binary yes/no rather than kernel internal secid
  • From: James Morris <jmorris@xxxxxxxxx>
• Re: redirecting connections to userspace
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: string and u32 modules
  • From: Greg Oliver <oliver.greg@xxxxxxxxx>
• redirecting connections to userspace
  • From: rhn <vamali.rhn@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 3/6] secmark: export binary yes/no rather than kernel internal secid
  • From: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
• Re: [PATCH 2/6] secmark: make secmark object handling generic
  • From: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
• Re: [PATCH 5/6] conntrack: export lsm context rather than internal secid via netlink
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: [PATCH 1/6] secmark: do not return early if there was no error
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• [PATCH 2/6] secmark: make secmark object handling generic
  • From: Eric Paris <eparis@xxxxxxxxxx>
• [PATCH 1/6] secmark: do not return early if there was no error
  • From: Eric Paris <eparis@xxxxxxxxxx>
• [PATCH 5/6] conntrack: export lsm context rather than internal secid via netlink
  • From: Eric Paris <eparis@xxxxxxxxxx>
• [PATCH 4/6] security: secid_to_secctx returns len when data is NULL
  • From: Eric Paris <eparis@xxxxxxxxxx>
• [PATCH 3/6] secmark: export binary yes/no rather than kernel internal secid
  • From: Eric Paris <eparis@xxxxxxxxxx>
• [PATCH 6/6] secmark: export secctx, drop secmark in procfs
  • From: Eric Paris <eparis@xxxxxxxxxx>
• netfilter_conntrack question - getting invalid argument
  • From: Steven Ayre <steveayre@xxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• string and u32 modules
  • From: Greg Oliver <oliver.greg@xxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Tom Eastep <teastep@xxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Eric Paris <eparis@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Eric Paris <eparis@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Eric Paris <eparis@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Eric Paris <eparis@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Eric Paris <eparis@xxxxxxxxxxxxxx>
• TCP ack in libnetfilter_queue
  • From: Mistick Levi <gmistick@xxxxxxxxx>
• Userspace control of load balancing via DNAT/IPVS
  • From: Steven Ayre <steveayre@xxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Tom Eastep <teastep@xxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Eric Paris <eparis@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Eric Paris <eparis@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Eric Paris <eparis@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: Help with compiling netfilter/iptables modules
  • From: Josu Gomez <jgomezp81@xxxxxxxxxxxxxx>
• Re: Help with compiling netfilter/iptables modules
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Help with compiling netfilter/iptables modules
  • From: Josu Gomez <jgomezp81@xxxxxxxxxxxxxx>
• Re: Help with compiling netfilter/iptables modules
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Help with compiling netfilter/iptables modules
  • From: Josu Gomez <jgomezp81@xxxxxxxxxxxxxx>
• Re: Help with compiling netfilter/iptables modules
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Help with compiling netfilter/iptables modules
  • From: Josu Gomez <jgomezp81@xxxxxxxxxxxxxx>
• Re: Help with compiling netfilter/iptables modules
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: How to log NAT translations
  • From: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: How to log NAT translations
  • From: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
• Re: How to log NAT translations
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Help with compiling netfilter/iptables modules
  • From: Josu Gomez <jgomezp81@xxxxxxxxxxxxxx>
• Re: Basic Routing
  • From: Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxx>
• Re: How to log NAT translations
  • From: Italo Valcy <italo@xxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Tom Eastep <teastep@xxxxxxxxxxxxx>
• Re: Basic Routing
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Help with compiling netfilter/iptables modules
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Help with compiling netfilter/iptables modules
  • From: Josu Gomez <jgomezp81@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Tom Eastep <teastep@xxxxxxxxxxxxx>
• Re: Basic Routing
  • From: "Daniel L. Miller" <dmiller@xxxxxxxxx>
• Re: Help with compiling netfilter/iptables modules
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Help with compiling netfilter/iptables modules
  • From: Josu Gomez <jgomezp81@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: help
  • From: Oskar Berggren <oskar.berggren@xxxxxxxxx>
• help
  • From: Marcos <mczueira@xxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: Ignore tcp checksum on ip_conntrack
  • From: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
• Re: decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• decipher the secmark number from nf_conntrack/ip_conntrack
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• Re: [rfc 13/13] [RFC 13/13] IPVS: sip persistence engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: [rfc 13/13] [RFC 13/13] IPVS: sip persistence engine
  • From: Julian Anastasov <ja@xxxxxx>
• Re: [patch v1 00/12] IPVS: SIP Persistence Engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: [patch v1 00/12] IPVS: SIP Persistence Engine
  • From: Patrick McHardy <kaber@xxxxxxxxx>
• Re: [patch v1 00/12] IPVS: SIP Persistence Engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Ignore tcp checksum on ip_conntrack
  • From: Alex Bligh <alex@xxxxxxxxxxx>
• Re: [patch v1 00/12] IPVS: SIP Persistence Engine
  • From: Patrick McHardy <kaber@xxxxxxxxx>
• Re: [PATCH 5/5] net/netfilter/ipvs: Eliminate memory leak
  • From: Patrick McHardy <kaber@xxxxxxxxx>
• RE: Is a match-all rule with jump to empty chain processed?
  • From: Data Shock <datashock@xxxxxxxxxxx>
• Re: Is a match-all rule with jump to empty chain processed?
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: How to log NAT translations
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• How to log NAT translations
  • From: Italo Valcy <italo@xxxxxxxxxxx>
• Packets occasionally not queued
  • From: Roger Sala <rsala@xxxxxxxx>
• Is a match-all rule with jump to empty chain processed?
  • From: Data Shock <datashock@xxxxxxxxxxx>
• nf_conntrack hashsize change during runtime?
  • From: Steven Kath <steven.kath@xxxxxxxxxx>
• Re: ULOGD and other logs
  • From: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
• ULOGD and other logs
  • From: ratheesh k <ratheesh.ksz@xxxxxxxxx>
• Re: SNAT problem
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: [ANNOUNCE] libnetfilter_conntrack 0.9.0 release
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: OpenVPN throttling problem
  • From: "J Webster" <webster_jack@xxxxxxxxxxx>
• help to build iptables rules for an oscar cluster
  • From: giggzounet <giggzounet@xxxxxxxxx>
• [ANNOUNCE] libnetfilter_conntrack 0.9.0 release
  • From: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
• Re: OpenVPN throttling problem
  • From: Payam Chychi <pchychi@xxxxxxxxx>
• Re: OpenVPN throttling problem
  • From: Thomas Jacob <jacob@xxxxxxxxxxxxx>
• Re: OpenVPN throttling problem
  • From: "J Webster" <webster_jack@xxxxxxxxxxx>
• Re: OpenVPN throttling problem
  • From: Thomas Jacob <jacob@xxxxxxxxxxxxx>
• Re: OpenVPN throttling problem
  • From: "J Webster" <webster_jack@xxxxxxxxxxx>
• Re: OpenVPN throttling problem
  • From: Thomas Jacob <jacob@xxxxxxxxxxxxx>
• Re: OpenVPN throttling problem
  • From: "J Webster" <webster_jack@xxxxxxxxxxx>
• Re: OpenVPN throttling problem
  • From: Thomas Jacob <jacob@xxxxxxxxxxxxx>
• Re: [Bugme-new] [Bug 16517] New: rp_filter fails to filter with CONFIG_IP_ROUTE_MULTIPATH and more than one 0/0 nexthop dev
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: rate of traffic that much a rule
  • From: vishesh kumar <linuxtovishesh@xxxxxxxxx>
• OpenVPN throttling problem
  • From: "J Webster" <webster_jack@xxxxxxxxxxx>
• tc add filter match src ip and mark
  • From: Mamadou Touré <e2ia.ci@xxxxxxxxx>
• Re: a single rule that mach source ip or destination ip
  • From: Mamadou Touré <e2ia.ci@xxxxxxxxx>
• Re: a single rule that mach source ip or destination ip
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: a single rule that mach source ip or destination ip
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: a single rule that mach source ip or destination ip
  • From: Brian Austin - Standard Universal <brian@xxxxxxxxxxxxxxxxxxxxxxxx>
• Re: a single rule that mach source ip or destination ip
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re:a single rule that mach source ip or destination ip
  • From: arimus.uk@xxxxxxxxx
• a single rule that mach source ip or destination ip
  • From: Mamadou Touré <e2ia.ci@xxxxxxxxx>
• Re: Need for a specific source address selection rule ? (not neccessarily netfilter)
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Need for a specific source address selection rule ? (not neccessarily netfilter)
  • From: Xavier Roche <roche*lkml@xxxxxxxxxxx>
• Re: Need for a specific source address selection rule ? (not neccessarily netfilter)
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Need for a specific source address selection rule ? (not neccessarily netfilter)
  • From: Xavier Roche <roche*lkml@xxxxxxxxxxx>
• Re: Need for a specific source address selection rule ? (not neccessarily netfilter)
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Need for a specific source address selection rule ? (not neccessarily netfilter)
  • From: Xavier Roche <roche*lkml@xxxxxxxxxxx>
• Re: Awkward scenario: 3 interfaces and 3 devices with same ip/subnet.
  • From: Marek Kierdelewicz <marek@xxxxxxxxx>
• Re: Awkward scenario: 3 interfaces and 3 devices with same ip/subnet.
  • From: Giacomo Bernardi <mino@xxxxxxxx>
• Re: Awkward scenario: 3 interfaces and 3 devices with same ip/subnet.
  • From: Marek Kierdelewicz <marek@xxxxxxxxx>
• Re: Awkward scenario: 3 interfaces and 3 devices with same ip/subnet.
  • From: Giacomo Bernardi <mino@xxxxxxxx>
• Re: Awkward scenario: 3 interfaces and 3 devices with same ip/subnet.
  • From: Marek Kierdelewicz <marek@xxxxxxxxx>
• Re: Awkward scenario: 3 interfaces and 3 devices with same ip/subnet.
  • From: Giacomo Bernardi <mino@xxxxxxxx>
• Re: rate of traffic that mach a rule
  • From: Richard Horton <arimus.uk@xxxxxxxxx>
• Re: rate of traffic that mach a rule
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• rate of traffic that mach a rule
  • From: Mamadou Touré <e2ia.ci@xxxxxxxxx>
• Re: Awkward scenario: 3 interfaces and 3 devices with same ip/subnet.
  • From: Marek Kierdelewicz <marek@xxxxxxxxx>
• change to max length of jump target
  • From: Stig Thormodsrud <stig@xxxxxxxxxx>
• NF_QUEUE: nfq_bind_pf() fails - solution
  • From: Athanasius <link@xxxxxxxxx>
• Need advise on none authenticate hotspot
  • From: ks ks <harlem.kks@xxxxxxxxx>
• Re: Awkward scenario: 3 interfaces and 3 devices with same ip/subnet.
  • From: Giacomo Bernardi <mino@xxxxxxxx>
• Re: Awkward scenario: 3 interfaces and 3 devices with same ip/subnet.
  • From: Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxx>
• Re: Awkward scenario: 3 interfaces and 3 devices with same ip/subnet.
  • From: Giacomo Bernardi <mino@xxxxxxxx>
• Re: Awkward scenario: 3 interfaces and 3 devices with same ip/subnet.
  • From: Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxx>
• Re: [PATCH] netfilter: remove duplicate include line
  • From: Vlad Dogaru <ddvlad@xxxxxxxxxx>
• Re: Awkward scenario: 3 interfaces and 3 devices with same ip/subnet.
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• [PATCH] netfilter: remove duplicate include line
  • From: Vlad Dogaru <ddvlad@xxxxxxxxxx>
• Awkward scenario: 3 interfaces and 3 devices with same ip/subnet.
  • From: Giacomo Bernardi <mino@xxxxxxxx>
• Re: aligned_{u64,be64,le64} defined in #ifdef __KERNEL__
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: NDP and ebtables
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: ebtables and anti-spoofing rules not working 100%?
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: ebtables and anti-spoofing rules not working 100%?
  • From: Tomasz Chmielewski <mangoo@xxxxxxxx>
• Re: ebtables and anti-spoofing rules not working 100%?
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Traffic Shaping
  • From: Narendra Choyal <narendrachoyal@xxxxxxxxx>
• Re: IPv6 routing
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: IPv6 routing
  • From: Thomas Jacob <jacob@xxxxxxxxxxxxx>
• Re: IPv6 routing
  • From: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
• Re: aligned_{u64,be64,le64} defined in #ifdef __KERNEL__
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: IPv6 routing
  • From: Thomas Jacob <jacob@xxxxxxxxxxxxx>
• Re: IPv6 routing
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: IPv6 routing
  • From: Thomas Jacob <jacob@xxxxxxxxxxxxx>
• Re: IPv6 routing
  • From: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
• Re: IPv6 routing
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: IPv6 routing
  • From: Thomas Jacob <jacob@xxxxxxxxxxxxx>
• Re: IPv6 routing
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: IPv6 routing
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: IPv6 routing
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: aligned_{u64,be64,le64} defined in #ifdef __KERNEL__
  • From: Andreas Gruenbacher <agruen@xxxxxxx>
• Re: IPv6 routing
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: IPv6 routing
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: IPv6 routing
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• IPv6 routing
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: aligned_{u64,be64,le64} defined in #ifdef __KERNEL__
  • From: David Miller <davem@xxxxxxxxxxxxx>
• aligned_{u64,be64,le64} defined in #ifdef __KERNEL__
  • From: Andreas Gruenbacher <agruen@xxxxxxx>
• Re: NDP and ebtables
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: ebtables and anti-spoofing rules not working 100%?
  • From: Tomasz Chmielewski <mangoo@xxxxxxxx>
• Re: ebtables and anti-spoofing rules not working 100%?
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: ebtables and anti-spoofing rules not working 100%?
  • From: Tomasz Chmielewski <mangoo@xxxxxxxx>
• Re: ebtables and anti-spoofing rules not working 100%?
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: NDP and ebtables
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: ebtables and anti-spoofing rules not working 100%?
  • From: Tomasz Chmielewski <mangoo@xxxxxxxx>
• Re: Need for a specific source address selection rule ? (not neccessarily netfilter)
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: ebtables and anti-spoofing rules not working 100%?
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: using iptables with tun/tap interfaces? no rule sees tun/tap interface traffic
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Need for a specific source address selection rule ? (not neccessarily netfilter)
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: NDP and ebtables
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Need for a specific source address selection rule ? (not neccessarily netfilter)
  • From: Xavier Roche <roche*lkml@xxxxxxxxxxx>
• ebtables and anti-spoofing rules not working 100%?
  • From: Tomasz Chmielewski <mangoo@xxxxxxxx>
• Re: Need for a specific source address selection rule ? (not neccessarily netfilter)
  • From: Xavier Roche <roche*lkml@xxxxxxxxxxx>
• Re: Need for a specific source address selection rule ? (not neccessarily netfilter)
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Need for a specific source address selection rule ? (not neccessarily netfilter)
  • From: Xavier Roche <roche*lkml@xxxxxxxxxxx>
• Re: using iptables with tun/tap interfaces? no rule sees tun/tap interface traffic
  • From: Tomasz Chmielewski <mangoo@xxxxxxxx>
• Re: using iptables with tun/tap interfaces? no rule sees tun/tap interface traffic
  • From: Marek Kierdelewicz <marek@xxxxxxxxx>
• Re: Need for a specific source address selection rule ? (not neccessarily netfilter)
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: using iptables with tun/tap interfaces? no rule sees tun/tap interface traffic
  • From: Tomasz Chmielewski <mangoo@xxxxxxxx>
• Need for a specific source address selection rule ? (not neccessarily netfilter)
  • From: Xavier Roche <roche*lkml@xxxxxxxxxxx>
• Re: using iptables with tun/tap interfaces? no rule sees tun/tap interface traffic
  • From: Marek Kierdelewicz <marek@xxxxxxxxx>
• using iptables with tun/tap interfaces? no rule sees tun/tap interface traffic
  • From: Tomasz Chmielewski <mangoo@xxxxxxxx>
• NDP and ebtables
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: Problems compiling xtables-addons v1.28
  • From: Brian Schang <netfilter@xxxxxxxxxxxxxxxx>
• Re: Problems compiling xtables-addons v1.28
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Problems compiling xtables-addons v1.28
  • From: Brian Schang <netfilter@xxxxxxxxxxxxxxxx>
• Re: [PATCH 5/5] net/netfilter/ipvs: Eliminate memory leak
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 5/5] net/netfilter/ipvs: Eliminate memory leak
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: [PATCH 5/5] net/netfilter/ipvs: Eliminate memory leak
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 0/5] Eliminate memory leak
  • From: Julia Lawall <julia@xxxxxxx>
• Re: [PATCH 5/5] net/netfilter/ipvs: Eliminate memory leak
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: Bridges
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: OFF??? POINT-TO-POINT
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: OFF??? POINT-TO-POINT
  • From: Gáspár Lajos <swifty@xxxxxxxxxxx>
• Re: Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: OFF??? POINT-TO-POINT
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Bridges
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: OFF??? POINT-TO-POINT
  • From: Gáspár Lajos <swifty@xxxxxxxxxxx>
• Re: OFF??? POINT-TO-POINT
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• OFF??? POINT-TO-POINT
  • From: Gáspár Lajos <swifty@xxxxxxxxxxx>
• Re: Bridges
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• [PATCH 5/5] net/netfilter/ipvs: Eliminate memory leak
  • From: Julia Lawall <julia@xxxxxxx>
• Re: Forced lladdr change with bridge - or not?
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Karel Rericha <karel@xxxxxxxxx>
• Re: Full Cone NAT - Time elapsed inside local network
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Full Cone NAT - Time elapsed inside local network
  • From: Navid Mohaghegh <navid@xxxxxxxx>
• Full Cone NAT - Time elapsed inside local network
  • From: Navid Mohaghegh <navid@xxxxxxxx>
• Re: Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: routing VPN users through transparent Squid using iptables
  • From: François Legal <francois.legal@xxxxxxxxxxxxxx>
• Re: Forced lladdr change with bridge - or not?
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: routing VPN users through transparent Squid using iptables
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Forced lladdr change with bridge - or not?
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Forced lladdr change with bridge - or not?
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: routing VPN users through transparent Squid using iptables
  • From: François Legal <devel@xxxxxxxxxxxxxx>
• Re: Forced lladdr change with bridge - or not?
  • From: bdschuym@xxxxxxxxxx
• Re: Forced lladdr change with bridge - or not?
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: SNAT problem
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Forced lladdr change with bridge - or not?
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Traffic Shaping
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• SNAT problem
  • From: Yevgeny Kosarzhevsky <deza50293@xxxxxx>
• Re: Forced lladdr change with bridge - or not?
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Forced lladdr change with bridge - or not?
  • From: Bart De Schuymer <bdschuym@xxxxxxxxxx>
• Forced lladdr change with bridge - or not?
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: routing VPN users through transparent Squid using iptables
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• [patch v1 12/12] IPVS: sip persistence engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v1 11/12] IPVS: Fallback if persistence engine fails
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v1 10/12] IPVS: Allow configuration of persistence engines
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v1 09/12] IPVS: management of persistence engine modules
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v1 08/12] IPVS: Add persistence engine data to /proc/net/ip_vs_conn
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v1 07/12] IPVS: Add struct ip_vs_pe
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v1 06/12] IPVS: ip_vs_{un,}bind_scheduler NULL arguments
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v1 05/12] IPVS: Allow null argument to ip_vs_scheduler_put()
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: [patch v1 00/12] IPVS: SIP Persistence Engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v1 04/12] IPVS: Add struct ip_vs_conn_param
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v1 03/12] IPVS: compact ip_vs_sched_persist()
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v1 2/2] [PATCH 2/2] Add support for persistence engines.
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v1 02/12] netfilter: nf_conntrack_sip: Add callid parser
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v1 1/2] [PATCH 1/2] Slightly simplify options conflicts logic
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v1 01/12] netfilter: nf_conntrack_sip: Allow ct_sip_get_header() to be called with a null ct argument
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v1 0/2] ipvsadm: SIP Persistence Engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v1 00/12] IPVS: SIP Persistence Engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• routing VPN users through transparent Squid using iptables
  • From: Jack Andrews <jack@xxxxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: Bridges
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: Bridges
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: Bridges
  • From: Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Bridges
  • From: Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Bridges
  • From: Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Bridges
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: Bridges
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: Bridges
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: Bridges
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: Bridges
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Bridges
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: Bridges
  • From: Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Rick Jones <rick.jones2@xxxxxx>
• Re: Bridges
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Bridges
  • From: Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Bridges
  • From: Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Bridges
  • From: Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Bridges
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: Bridges
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: Bridges
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: Bridges
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: Bridges
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: Bridges
  • From: Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: Bridges
  • From: Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxx>
• Re: Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Re: Bridges
  • From: Thomas Jacob <jacob@xxxxxxxxxxxxx>
• Re: Bridges
  • From: Stephen Hemminger <shemminger@xxxxxxxxxx>
• Re: Bridges
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Bridges
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• [ANNOUNCE] ipset-4.3
  • From: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
• Re: iptable and tproxy target
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: QoS weirdness : HTB accuracy
  • From: Jussi Kivilinna <jukivili@xxxxxxxxx>
• Re: nfnetlink_queue interfering with ioctl calls
  • From: Roger Sala <rsala@xxxxxxxx>
• nfnetlink_queue interfering with ioctl calls
  • From: Roger Sala <rsala@xxxxxxxx>
• iptable and tproxy target
  • From: Mamadou Touré <e2ia.ci@xxxxxxxxx>
• mmotm 2010-08-11 - lockdep whinges at e1000e driver ifconfig up
  • From: Valdis.Kletnieks@xxxxxx
• Some problems with NAT, can't connect fo a few hosts, but the rest works
  • From: Hauke Hoffmann <kontakt@xxxxxxxxxxxxxxxxxx>
• Re: ebtables nflog problem
  • From: Angel Inkov <bl8cki@xxxxxxxxx>
• Re: QoS weirdness : HTB accuracy
  • From: Andrew Beverley <andy@xxxxxxxxxxx>
• Re: Howto DNAT/SNAT existing TCP session (no SYN, only PUSH/ACK)
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: QoS weirdness : HTB accuracy
  • From: Andrew Beverley <andy@xxxxxxxxxxx>
• Howto DNAT/SNAT existing TCP session (no SYN, only PUSH/ACK)
  • From: Norbert van Bolhuis <nvbolhuis@xxxxxxxxxxxx>
• ebtables nflog problem
  • From: Angel Inkov <bl8cki@xxxxxxxxx>
• Re: netfilter: add xt_cpu match
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: netfilter: add xt_cpu match
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: openvpn over udp failing
  • From: Billy Crook <billycrook@xxxxxxxxx>
• Re: firewall and squid running on the same box
  • From: Mamadou Touré <e2ia.ci@xxxxxxxxx>
• Re: openvpn over udp failing
  • From: Billy Crook <billycrook@xxxxxxxxx>
• Re: openvpn over udp failing
  • From: "J Webster" <webster_jack@xxxxxxxxxxx>
• Re: openvpn over udp failing
  • From: Billy Crook <billycrook@xxxxxxxxx>
• Re: openvpn over udp failing
  • From: "J Webster" <webster_jack@xxxxxxxxxxx>
• Re: openvpn over udp failing
  • From: Billy Crook <billycrook@xxxxxxxxx>
• Re: openvpn over udp failing
  • From: "J Webster" <webster_jack@xxxxxxxxxxx>
• Re: openvpn over udp failing
  • From: Billy Crook <billycrook@xxxxxxxxx>
• Re: openvpn over udp failing
  • From: "J Webster" <webster_jack@xxxxxxxxxxx>
• Re: openvpn over udp failing
  • From: Billy Crook <billycrook@xxxxxxxxx>
• Re: iptables / ebtables IP address intercept
  • From: Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxx>
• Re: Different limits in 32bit vs 64bit?
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• openvpn over udp failing
  • From: "J Webster" <webster_jack@xxxxxxxxxxx>
• Different limits in 32bit vs 64bit?
  • From: Ethan Sommer <sommere@xxxxxxx>
• Re: [rfc 02/13] [RFC 02/13] netfilter: nf_conntrack_sip: Add callid parser
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: [rfc 02/13] [RFC 02/13] netfilter: nf_conntrack_sip: Add callid parser
  • From: Patrick McHardy <kaber@xxxxxxxxx>
• [ANNOUNCE]: Release of iptables-1.4.9.1
  • From: Patrick McHardy <kaber@xxxxxxxxx>
• Re: [ANNOUNCE]: Release of iptables-1.4.9
  • From: Patrick McHardy <kaber@xxxxxxxxx>
• Re: [rfc 10/13] [RFC 10/13] IPVS: management of persistence engine modules
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: [rfc 13/13] [RFC 13/13] IPVS: sip persistence engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: [rfc 09/13] [RFC 09/13] IPVS: Add persistence engine data to /proc/net/ip_vs_conn
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: [Bugme-new] [Bug 16517] New: rp_filter fails to filter with CONFIG_IP_ROUTE_MULTIPATH and more than one 0/0 nexthop dev
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• [PATCH 16/42] net/ipv6/netfilter: Adjust confusing if indentation
  • From: Julia Lawall <julia@xxxxxxx>
• Re: [rfc 10/13] [RFC 10/13] IPVS: management of persistence engine modules
  • From: Stephen Hemminger <shemminger@xxxxxxxxxx>
• [2.6.35 regression] iptables busted on Mac G5
  • From: Mikael Pettersson <mikpe@xxxxxxxx>
• Re: [rfc 13/13] [RFC 13/13] IPVS: sip persistence engine
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: [rfc 09/13] [RFC 09/13] IPVS: Add persistence engine data to /proc/net/ip_vs_conn
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• [rfc 2/2] [PATCH 2/2] Add support for persistence engines.
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [rfc 1/2] [PATCH 1/2] Slightly simplify options conflicts logic
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [rfc 0/2] ipvsadm: SIP Persistence Engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [rfc 13/13] [RFC 13/13] IPVS: sip persistence engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [rfc 12/13] [RFC 12/13] IPVS: Fallback if persistence engine fails
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [rfc 11/13] [RFC 11/13] IPVS: Allow configuration of persistence engines
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [rfc 10/13] [RFC 10/13] IPVS: management of persistence engine modules
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [rfc 09/13] [RFC 09/13] IPVS: Add persistence engine data to /proc/net/ip_vs_conn
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [rfc 08/13] [RFC 08/13] IPVS: Add struct ip_vs_pe
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [rfc 07/13] [RFC 07/13] IPVS: ip_vs_{un,}bind_scheduler NULL arguments
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [rfc 06/13] [RFC 06/13] IPVS: Allow null argument to ip_vs_scheduler_put()
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [rfc 05/13] [RFC 05/13] IPVS: Add struct ip_vs_conn_param
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [rfc 04/13] [RFC 04/13] IPVS: compact ip_vs_sched_persist()
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [rfc 03/13] [RFC 03/13] ipvs: provide default ip_vs_conn_{in,out}_get_proto
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [rfc 02/13] [RFC 02/13] netfilter: nf_conntrack_sip: Add callid parser
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [rfc 01/13] [RFC 01/13] netfilter: nf_conntrack_sip: Allow ct_sip_get_header() to be called with a null ct argument
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [rfc 00/13] IPVS: SIP Persistence Engine
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: ebtables PREROUTING -drop
  • From: ratheesh k <ratheesh.ksz@xxxxxxxxx>
• Re: ebtables PREROUTING -drop
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: ebtables PREROUTING -drop
  • From: ratheesh k <ratheesh.ksz@xxxxxxxxx>
• Re: [ANNOUNCE]: Release of iptables-1.4.9
  • From: "Gabor Z. Papp" <gzp@xxxxxxx>
• Re: [Bridge] ebtables PREROUTING -drop
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: [Bridge] ebtables PREROUTING -drop
  • From: Nicolas de Pesloüan <nicolas.2p.debian@xxxxxxx>
• Re: [ANNOUNCE]: Release of iptables-1.4.9
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: [ANNOUNCE]: Release of iptables-1.4.9
  • From: Patrick McHardy <kaber@xxxxxxxxx>
• Re: Clone Filter Table
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Clone Filter Table
  • From: Edison Figueira <efjgrub@xxxxxxxxx>
• Re: [Bridge] ebtables PREROUTING -drop
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: [Bridge] ebtables PREROUTING -drop
  • From: Alex Bligh <alex@xxxxxxxxxxx>
• Re: [Bridge] ebtables PREROUTING -drop
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: [Bridge] ebtables PREROUTING -drop
  • From: Alex Bligh <alex@xxxxxxxxxxx>
• Re: [Bridge] ebtables PREROUTING -drop
  • From: Nicolas de Pesloüan <nicolas.2p.debian@xxxxxxx>
• Re: ebtables PREROUTING -drop
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• ebtables PREROUTING -drop
  • From: ratheesh k <ratheesh.ksz@xxxxxxxxx>
• Re: iptables / ebtables IP address intercept
  • From: Alex Bligh <alex@xxxxxxxxxxx>
• RE: snat range not cycling
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• RE: snat range not cycling
  • From: "Timothy Hayes" <morphieus@xxxxxxxxxxxxx>
• Re: snat range not cycling
  • From: "\"Oleg A. Arkhangelsky\"" <sysoleg@xxxxxxxxx>
• Re: snat range not cycling
  • From: "\"Oleg A. Arkhangelsky\"" <sysoleg@xxxxxxxxx>
• Re: firewall and squid running on the same box
  • From: Mamadou Touré <e2ia.ci@xxxxxxxxx>
• Re: snat range not cycling
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• snat range not cycling
  • From: "Timothy Hayes" <morphieus@xxxxxxxxxxxxx>
• Re: iptables / ebtables IP address intercept
  • From: Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxx>
• Re: [ANNOUNCE]: Release of iptables-1.4.9
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: [ANNOUNCE]: Release of iptables-1.4.9
  • From: "Gabor Z. Papp" <gzp@xxxxxxx>
• Re: iptables / ebtables IP address intercept
  • From: Alex Bligh <alex@xxxxxxxxxxx>
• Re: [ANNOUNCE]: Release of iptables-1.4.9
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: [ANNOUNCE]: Release of iptables-1.4.9
  • From: Michele Petrazzo - Unipex <michele.petrazzo@xxxxxxxxx>
• Re: [ANNOUNCE]: Release of iptables-1.4.9
  • From: "Gabor Z. Papp" <gzp@xxxxxxx>
• Re: [ANNOUNCE]: Release of iptables-1.4.9
  • From: "Gabor Z. Papp" <gzp@xxxxxxx>
• Re: [ANNOUNCE]: Release of iptables-1.4.9
  • From: Patrick McHardy <kaber@xxxxxxxxx>
• Re: [ANNOUNCE]: Release of iptables-1.4.9
  • From: "Gabor Z. Papp" <gzp@xxxxxxx>
• Re: iptables / ebtables IP address intercept
  • From: Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxx>
• [ANNOUNCE]: Release of iptables-1.4.9
  • From: Patrick McHardy <kaber@xxxxxxxxx>
• Re: libnfcontrack weirdness
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: libnetfilter_conntrack callbacks and nfct_destroy
  • From: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
• Re: libnfcontrack weirdness
  • From: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
• libnetfilter_conntrack callbacks and nfct_destroy
  • From: Andrew Beverley <andy@xxxxxxxxxxx>
• Re: libnfcontrack weirdness
  • From: Alex Bligh <alex@xxxxxxxxxxx>
• Re: libnfcontrack weirdness
  • From: Andrew Beverley <andy@xxxxxxxxxxx>
• Re: libnfcontrack weirdness
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: libnfcontrack weirdness
  • From: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
• Re: libnfcontrack weirdness
  • From: Andrew Beverley <andy@xxxxxxxxxxx>
• libnfcontrack weirdness
  • From: Alex Bligh <alex@xxxxxxxxxxx>
• Re: firewall and squid running on the same box
  • From: Marek Kierdelewicz <marek@xxxxxxxxx>
• firewall and squid running on the same box
  • From: Mamadou Touré <e2ia.ci@xxxxxxxxx>
• Re: ipv6 forwarding without netfilter
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: ipv6 forwarding without netfilter
  • From: ABPNI <jonnyt@xxxxxxxxxxx>
• Re: ipv6 forwarding without netfilter
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• ipv6 forwarding without netfilter
  • From: Mark Ryden <markryde@xxxxxxxxx>
• iptables / ebtables IP address intercept
  • From: Alex Bligh <alex@xxxxxxxxxxx>
• Re: iptables rule for ovh
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: iptables rule for ovh
  • From: Portedaix <portedaix@xxxxxxxxx>
• Re: block network access for certain users/groups
  • From: Richard Horton <arimus.uk@xxxxxxxxx>
• Re: block network access for certain users/groups
  • From: Elmar Stellnberger <estellnb@xxxxxxxxx>
• Re: block network access for certain users/groups
  • From: Lars Nooden <lars.curator@xxxxxxxxx>
• Re: strange log on gateway inside []
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: strange log on gateway inside []
  • From: Richard Horton <arimus.uk@xxxxxxxxx>
• Re: strange log on gateway inside []
  • From: Michele Petrazzo - Unipex <michele.petrazzo@xxxxxxxxx>
• Re: Synflood filtering and Conntrack
  • From: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
• Re: block network access for certain users/groups
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Synflood filtering and Conntrack
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Synflood filtering and Conntrack
  • From: Mart Frauenlob <mart.frauenlob@xxxxxxxxx>
• SNAT - on bridge only addressing some packets?
  • From: "Timothy Hayes" <morphieus@xxxxxxxxxxxxx>
• Re: block network access for certain users/groups
  • From: Richard Horton <arimus.uk@xxxxxxxxx>
• Re: block network access for certain users/groups
  • From: Lars Nooden <lars.curator@xxxxxxxxx>
• block network access for certain users/groups
  • From: "Elmar Stellnberger" <estellnb@xxxxxxxxx>
• block network access for certain users/groups
  • From: "Elmar Stellnberger" <estellnb@xxxxxxxxx>
• Re: Synflood filtering and Conntrack
  • From: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
• Re: Synflood filtering and Conntrack
  • From: Gáspár Lajos <swifty@xxxxxxxxxxx>
• Re: Synflood filtering and Conntrack
  • From: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
• Re: Synflood filtering and Conntrack
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• "Expect" from Netfilter hook
  • From: Jackson Alberto <superj_2004@xxxxxxxxxxx>
• Re: Synflood filtering and Conntrack
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Synflood filtering and Conntrack
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Synflood filtering and Conntrack
  • From: Mart Frauenlob <mart.frauenlob@xxxxxxxxx>
• Re: Synflood filtering and Conntrack
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Synflood filtering and Conntrack
  • From: Mart Frauenlob <mart.frauenlob@xxxxxxxxx>
• Re: iptables rule for ovh
  • From: Richard Horton <arimus.uk@xxxxxxxxx>
• Re: strange log on gateway inside []
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: iptables rule for ovh
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: iptables rule for ovh
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: iptables rule for ovh
  • From: Richard Horton <arimus.uk@xxxxxxxxx>
• Re: iptables rule for ovh
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: strange log on gateway inside []
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: strange log on gateway inside []
  • From: Michele Petrazzo - Unipex <michele.petrazzo@xxxxxxxxx>
• iptables rule for ovh
  • From: Portedaix <portedaix@xxxxxxxxx>
• Re: strange log on gateway inside []
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• strange log on gateway inside []
  • From: Michele Petrazzo - Unipex <michele.petrazzo@xxxxxxxxx>
• Re: Synflood filtering and Conntrack
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: Synflood filtering and Conntrack
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Synflood filtering and Conntrack
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• RE: Bidirectionally Route all traffic to an ip to another ip
  • From: <jwexler@xxxxxxxxxxxx>
• RE: Bidirectionally Route all traffic to an ip to another ip
  • From: <jwexler@xxxxxxxxxxxx>
• Re: How Expensive?
  • From: Payam Chychi <pchychi@xxxxxxxxx>
• Re: How Expensive?
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Synflood filtering and Conntrack
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Synflood filtering and Conntrack
  • From: Mart Frauenlob <mart.frauenlob@xxxxxxxxx>
• Re: How Expensive?
  • From: Payam Chychi <pchychi@xxxxxxxxx>
• How Expensive?
  • From: Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
• Synflood filtering and Conntrack
  • From: "Dennis J." <dennisml@xxxxxxxxxxxx>
• Re: match streaming traffic in iptable rule
  • From: Pieter Smit <mlist2010@xxxxxxxxxxx>
• Re: match streaming traffic in iptable rule
  • From: Mart Frauenlob <mart.frauenlob@xxxxxxxxx>
• Re: match streaming traffic in iptable rule
  • From: Mamadou Touré <e2ia.ci@xxxxxxxxx>
• Re: match streaming traffic in iptable rule
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• match streaming traffic in iptable rule
  • From: Mamadou Touré <e2ia.ci@xxxxxxxxx>
• Re: making QoS for FTP traffic using tc HTB
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: IPP2P-0.8.2 install for iptable 1.4.4 on linux kernel 2.3.32
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: making QoS for FTP traffic using tc HTB
  • From: Andrew Beverley <andy@xxxxxxxxxxx>
• IPP2P-0.8.2 install for iptable 1.4.4 on linux kernel 2.3.32
  • From: Mamadou Touré <e2ia.ci@xxxxxxxxx>
• Re: CLUSTERIP: no conntrack error
  • From: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
• Re: CLUSTERIP: no conntrack error
  • From: Edison Figueira <efjgrub@xxxxxxxxx>
• Re: CLUSTERIP: no conntrack error
  • From: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
• Re: CLUSTERIP: no conntrack error
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• RE: Bidirectionally Route all traffic to an ip to another ip
  • From: <jwexler@xxxxxxxxxxxx>
• Re: CLUSTERIP: no conntrack error
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: CLUSTERIP: no conntrack error
  • From: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
• Re: Bidirectionally Route all traffic to an ip to another ip
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Bidirectionally Route all traffic to an ip to another ip
  • From: <jwexler@xxxxxxxxxxxx>
• Re: Limiting bandwidth on router
  • From: Elison Niven <elison.niven@xxxxxxxxx>
• Re: about conntrack for oracle tns
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: CLUSTERIP: no conntrack error
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Problem with arptables et mangle
  • From: ZHOU Xiaobo <xb.zhou@xxxxxx>
• Re: Problem with NAT rule
  • From: Pete Kay <petedao@xxxxxxxxx>
• Problem with arptables et mangle
  • From: Antoine Souques <corum@xxxxxxxxxx>
• Re: Problem with NAT rule
  • From: ZHOU Xiaobo <xb.zhou@xxxxxx>
• Re: Problem with NAT rule
  • From: Pieter Smit <mlist2010@xxxxxxxxxxx>
• Re: Limiting bandwidth on router
  • From: Elison Niven <elison.niven@xxxxxxxxx>
• Re: Problem with NAT rule
  • From: Pete Kay <petedao@xxxxxxxxx>
• Re: Problem with NAT rule
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Problem with NAT rule
  • From: Pete Kay <petedao@xxxxxxxxx>
• Re: Limiting bandwidth on router
  • From: Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx>
• Re: [patch v2.8 4/4] [patch v2.2 4/4] [PATCH v2.1 4/4] libxt_ipvs: user-space lib for netfilter matcher xt_ipvs
  • From: Patrick McHardy <kaber@xxxxxxxxx>
• Re: Limiting bandwidth on router
  • From: Richard Horton <arimus.uk@xxxxxxxxx>
• Re: [patch v2.8 3/4] IPVS: make FTP work with full NAT support
  • From: Patrick McHardy <kaber@xxxxxxxxx>
• Re: [patch v2.8 2/4] IPVS: make friends with nf_conntrack
  • From: Patrick McHardy <kaber@xxxxxxxxx>
• Re: [patch v2.8 1/4] netfilter: xt_ipvs (netfilter matcher for IPVS)
  • From: Patrick McHardy <kaber@xxxxxxxxx>
• Limiting bandwidth on router
  • From: Elison Niven <elison.niven@xxxxxxxxx>
• Re: Regarding write send a packet to network that received in NF_IP_PRE_ROUTING
  • From: Padmalochan Moharana <padman.m@xxxxxxxxx>
• Re: Regarding write send a packet to network that received in NF_IP_PRE_ROUTING
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: Regarding write send a packet to network that received in NF_IP_PRE_ROUTING
  • From: Padmalochan Moharana <padman.m@xxxxxxxxx>
• Re: Regarding write send a packet to network that received in NF_IP_PRE_ROUTING
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• [patch v2.8 4/4] [patch v2.2 4/4] [PATCH v2.1 4/4] libxt_ipvs: user-space lib for netfilter matcher xt_ipvs
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v2.8 3/4] IPVS: make FTP work with full NAT support
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v2.8 2/4] IPVS: make friends with nf_conntrack
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v2.8 1/4] netfilter: xt_ipvs (netfilter matcher for IPVS)
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• [patch v2.8 0/4] IPVS full NAT support + netfilter 'ipvs' match support
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: [patch v2.6 4/4] libxt_ipvs: user-space lib for netfilter matcher xt_ipvs
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: [patch v2.6 4/4] libxt_ipvs: user-space lib for netfilter matcher xt_ipvs
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: [patch v2.6 4/4] libxt_ipvs: user-space lib for netfilter matcher xt_ipvs
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• libnetfilter_queue hardware checksum
  • From: George Roussos <g.roussos@xxxxxxxxxxxxx>
• Re: IPTables physdev and bond0
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• IPTables physdev and bond0
  • From: Benjamin Kingston <list@xxxxxxxxxxxxxxx>
• Re: question about esp and policy matching rule
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: question about esp and policy matching rule
  • From: Sergei Zhirikov <sfzhi@xxxxxxxxx>
• Re: [patch v2.6 4/4] libxt_ipvs: user-space lib for netfilter matcher xt_ipvs
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: [patch v2.6 4/4] libxt_ipvs: user-space lib for netfilter matcher xt_ipvs
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: [patch v2.6 4/4] libxt_ipvs: user-space lib for netfilter matcher xt_ipvs
  • From: Simon Horman <horms@xxxxxxxxxxxx>
• Re: [patch v2.6 4/4] libxt_ipvs: user-space lib for netfilter matcher xt_ipvs
  • From: Jan Engelhardt <jengelh@xxxxxxxxxx>
• Re: [patch v2.7 4/4] libxt_ipvs: user-space lib for netfilter matcher xt_ipvs
  • From: Simon Horman <horms@xxxxxxxxxxxx>