Last time I posted it there was some disagreement regarding when/how
mangle was to be called. Maybe Harald has made up his mind now?
I have not had any reason to make any changes to CONNMARK since last
posted I think (the last filemodification date is May 20). As you say
it works very well
QUEUE makes the packet leave the entire hook, meaning when userspace
sets the verdict then the packet will continue at the next netfilter
hook (if any). No further rules in the same hook will be processed.
This makes QUEUE somewhat pointless to use in the nat table as QUEUE
cannot do any
On Mondayen den 18 March 2002 16.35, Harald Welte wrote:
Just as a small note to all people maintaining conntrack/NAT helpers:
Please port your helpers to the newnat code, I will have to temporarily
remove them from CVS as soon as newnat apprears in the mainstream kernel.
This applies to all
[cannot claim I have been following the thread closely, mostly
guessing on what you are actually trying to acheive here.. so I may
be way off]
On Tuesday 19 March 2002 12:19, Jean-Michel Hemstedt wrote:
REDIRECT could work in case of collocated proxy, and only if we
have control on the
Right. For this with iptables the standard solution is to run a small proxy
on the iptables box, and have iptables extended to allow this proxy to
control the source address of outgoing connections.
Unfortunately this functionality isn't easily achievable in iptables at the
moment. iptables
On Wednesdayen den 20 March 2002 12.13, Leon Brooks wrote:
How about transproxying to Squid on the netfilter box, and getting Squid to
passthrough to the `real' proxy?
Won't solve the issue of not hiding the clients real IP addresses.
Regards
Henrik Nordström
Squid Developer Netfilter
On Wednesdayen den 20 March 2002 12.13, Leon Brooks wrote:
How about transproxying to Squid on the netfilter box, and getting Squid to
passthrough to the `real' proxy?
And also, Squid does not know how to intercept HTTPS traffic. But adding such
functionality to Squid is trivial if needed.
The connection addressing information, including original and translated
addresses are found in the conntrack entry. There you can find
Original source IP/port, NAT source IP/port, original destination IP,
NAT destination IP and a lot more.
Regards
Henrik Nordstrom
ÀÌÈ£Àç wrote:
I'd
versions of the combined patch. One normal including
changes in indentation, and one diff -w that better shows the actual
changes.
Regards
Henrik
On Mondayen den 25 March 2002 11.11, Harald Welte wrote:
On Tue, Feb 19, 2002 at 04:43:12PM +0100, Henrik Nordstrom wrote:
Attached you will find a small
Pekka Savola wrote:
I take it you don't comment on how
ipchains/ipfwadm NAT does this? That knowledge would also be very much
appreciated as there are still (mostly) 2.2 -kernel boxes around.
The NAT capabilities of Linux-2.2 ipchains is quite limited, only having
masquerade NAT. It maps
The runme patch I sent a few days ago sort of allows you to do this.
Regards
Henrik Nordström
MARA Systems AB, Sweden
On Tuesdayen den 26 March 2002 21.18, Rodrigo Senra wrote:
Is there a way to define profiles to patch-o-matic.
I mean to define a subset of desired patches with Y as
Please don't forget UDP.
For UDP you need to save the original destination, and then implement a
control message extension for sending this to userspace together with the
packet in response to a recvmsg() call, or hack the kernel to return the
original destination in IP_PKTINFO (would be the
On Wednesday 27 March 2002 16.17, Jean-Michel Hemstedt wrote:
- If your proxy allows CONNECT requests, then virtually anything
can pass through it, and HTTPS decrypting proxy does not make sense.
A proxy can in theory verify that the supposedly SSL stream looks like a SSL
stream and not
Balazs Scheidler wrote:
Where is the possible transparent proxy entries defined? Internally in
TPROXY, or in the host IP stack socket table?
in TPROXY.
Is TPROXY is a stand-alone netfilter module, not a iptables target?
I thought it was a iptables target, but from your answer it seems
Balazs Scheidler wrote:
because we don't do full TCP tracking, and our NAT is quite limited. (only
DNAT, and only to local IP stack). And in addition entries are not
timeouted from the table.
a new entry is added to this table when
1) a TPROXY destination is encountered
2) when a socket
Patrick Schaaf wrote:
This won't handle DNS lookups for names resolving to more than one A record,
right? It would use the first A record found, as far as I know.
Right, as far as I know..
Same thing if you use the iptables command to install rules.
This has been discussed before here, on
Harald Welte wrote:
On Sun, Mar 31, 2002 at 06:10:35PM +0200, Henrik Nordstrom wrote:
Right.. SNAT was rejected by Harald as he sees no use of it. My original
patch posted on the netfilter-devel mailinglist supports both for
symmetry.
snat on locally-geerated packets has always beeen
On Tuesday 02 April 2002 19:15, [EMAIL PROTECTED] wrote:
You can't tell me that many uses of this patch are antisocial. In
fact, in its intended use, it would've substantially reduced the
amount of antisocial packets leaving my network. This is a tool
with interesting uses that the
On Tuesday 02 April 2002 23:40, Aaron Hopkins wrote:
And this was the method we employed. This involves adding a filter
for each offending IP. On a large network with new attack nodes
coming up every few seconds, its not necessarily possible to catch
them all quickly.
For this purpose we
Brian J. Murrell wrote:
decrease throughput, cause the connections to
stall
Well they only stall as long as it takes for TCP to resend the packet,
which should not be a huge amount of time.
Unless there is a artificial high packet delay such as a badly tuned queue,
in which case the TCP
On Monday 08 April 2002 00:28, Brian J. Murrell wrote:
Right! But my impression is that you have no idea which
application is requesting the access through the UPnP server. A
security policy of allow whatever the clients ask for is no
security policy at all, and unless the firewall/UPnP
On Monday 08 April 2002 05:36, Brian J. Murrell wrote:
But even with it, I have to trust the client app that it will do
good (and secure) with the hole in the firewall that I have
allocated for it.
See my earlier message. The holes should be subject to your
firewalling policy.
Oh. I see
On Monday 08 April 2002 16:29, Brian J. Murrell wrote:
If it is indeed possible to do this. How does the UPnP determine
for what purposes a client request is being made? If the answer is
well the client says what it is for then again, that is useless.
There is multiple choices here.
a)
On Monday 08 April 2002 18:03, Nils Ohlmeier wrote:
Brian you always wrote about trusting your clients. sarcastic If
you do not trust your clients don't connect them to the internet.
/sarcastic How do you know in detail what your clients send or
receive over connections to port 80? I assume
On Tuesday 09 April 2002 03:48, Brian J. Murrell wrote:
I must be missing something here because we seem be going around
and around on this issue. There are no defined ports that you
can discern what gets opened and what doesn't. It sounds to me
like all ports are ephemeral, which makes
On Tuesday 09 April 2002 03:48, Nils Ohlmeier wrote:
If i understand the spec correct, a UPnP deamon have also to
provide control over your ppp-deamon. The main aspect of the spec
is configuring and controling your dialup connection and the
posibility to configure port-forwarding is
Guillaume Lécroart wrote:
Then I thought of using policy routing to forward the ip packets directed
to tcp port 21 to the proxy box WITHOUT MODIFYING the DST IP address. Could
be funny and tricky, but I would need a way to do the same for the data
connections. Oh, of course, I could use a -m
Attached is an updated version of CONNMARK.patch where the
ip_conntrack_core.c conflict has been resolved.
This should allow CONNMARK to be moved back from oldnat to extra.
Regards
Henrik
diff -uN linux-2.4.3-pre3/include/linux/netfilter_ipv4/ip_conntrack.h
[this message was originally sent 2002-05-03, but I haven't heard
anything from you yet...]
Attached is an updated version of CONNMARK.patch where the
ip_conntrack_core.c conflict has been resolved.
This should allow CONNMARK to be moved back from oldnat to extra.
Regards
Henrik
diff -uN
Quite likely a duplex negotiation problem. Check the duplex setting
of the port where the firewall is connected, and the settings to the
NIC driver on your Linux box.
Having the switch configured for 100 Mbps full duplex rather than
auto is recommended. Not all switches and drivers agree on
On Monday 20 May 2002 16:02, Glover George wrote:
True, but I'm talking about only the INPUT, FORWARD, and OUTPUT
chains. Why would you need test data? There should be a way to
actually insert a packet into the real chains and see if it comes
out (some sort of hook to see if it's a test
How I do it is that I have a piece of software that generates my
entire ruleset according to set criteria. Everytime there is a
change the entire ruleset is regenerated and then installed by
iptables-restore in one atomic operation (well, one atomic operation
per table.. would be nice if
Patrick Schaaf wrote:
Could you possibly try newnat without ipsec, e.g. with a crossover cable
between the routers?
We were just willing to see if someone else encountered this problem and
knows more about it.
For what it is worth, I run the following setup just fine
client network -
Simon Brooke wrote:
I think I want to do it at user-space-handler-over-netfilter level.
Which is supported just fine for a proxy approach by the NAT framework..
So some types of SOAP message sent to host 'A' are valid, but all
others should be blocked; and any SOAP messages sent to 'C' and
[runme patch proposal for patch-o-matic dealing with the man page attached]
Hervé Eychenne wrote:
- TTL target had nothing to do here, as it is in patch-o-matic.
Deleted for coherence. Maybe we could have a special manpage for
extra extensions, but as they are already documented in the
And here is a version of the patch that actually seems to work... (the
previous slotted in the changes slightly wrong.. didn't notice the subtle
error before sending the patch)
Regards
Henrik
Henrik Nordstrom wrote:
And here is the actual patch...
Henrik Nordstrom wrote:
[runme patch
For this you will currently need to build your own conntrack helper.
Protocols having port numbers or IP addresses in their payload will
require helpers, but any protocol where the port numbers are well
defined should be fully usable with such a generic helper I suppose.
IDENT presents a bit
Balazs Scheidler wrote:
* use a new state (called TPROXY), which would be applied to all TPROXYed
packets (might interact badly with nat/conntrack).
It will in no doubt interact badly with connection tracking (and therefore
NAT).
* have the tproxy framework mark all packets with an
Balazs Scheidler wrote:
Will interact badly with fwmark based routing.
of course the mark value would be controlled by the user, and not assigned
automatically.
As routing rules cannot mask fwmark, anything that touches the fwmark value
for whatever purpose will affect your fwmark based
Don Cohen wrote:
Why do you think that's better than simply forwarding packets with
sequence/ack# translation? Surely it's less efficient. And it raises
questions about how much data to buffer between the two and how that
can be controlled.
Because there is no good way to know the servers
Emmanuel Fleury wrote:
So, what are the INVALID packets ?
Packets where it is impossible to identify a session key to use when matching
reply packets as belonging to the same session. This is mostly malformed
packets.
I think RST of a non-existing session also classifies as INVALID, but
Emmanuel Fleury wrote:
The core of the problem seems to be a conflict between two features:
1) The existing connections shouldn't be stopped when you change the
rules of your firewall at run time (something which occur much more
often than the reboot of one firewall).
2) The
Emmanuel Fleury wrote:
Henrik Nordstrom wrote:
This configuration can be done just fine with iptables as demonstrated in
my earlier message, but here we go again (but slightly different):
# Allow existing connections
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Emmanuel Fleury wrote:
Does this means that you are mapping the packets to a state (NEW,
ESTABLISHED, RELATED, INVALID) only based on information on their
header and a query to the connection table ? And that you do not
care about the previous state of the connection ?
No,
Rusty Russell wrote:
If their firewall reboots and is running iptables and thus Linux: How
long will it be down?
120 seconds to reboot with a fixed kernel...
More like 20 seconds with a standard modular kernel for firewall boxes with a
slimmed OS running on commodity hardware..
With a
Damiano Bolzoni wrote:
Hi people,
I wrote a kernel module that uses netfilter. I'm interested on incoming IP
packets that carry a TCP segment with SYN flag active. What I want to do is
to know which socket has been created in order to handle that connection
and I want to close it. sk_buff
On Tuesday 11 June 2002 09:59, Harald Welte wrote:
On Thu, Jun 06, 2002 at 02:24:04PM +0200, Martin Josefsson wrote:
This patch adds a check to ip_ct_refresh() so it doesn't update
the timer of a connection unless it's been HZ ticks since the
last update. both del_timer() and add_timer()
On Wednesday 12 June 2002 21:02, Martin Josefsson wrote:
It adds a new parameter to ip_ct_refresh called force, if set to
non-zero a timer update will be forced.
Hmm.. this may be a little hard to enforce at all times..
Why don't you make the filter simply filter out any timer updates that
See patch-o-matic/submitted/local-nat.patch
Regards
Henrik
On Sunday 16 June 2002 06:10, Ö£´«²¨ wrote:
we use linux as the firewall. we have a web server,as we made a
DNAT rule on the firewall,the people can visit it from internet by
address 202.38.128.1(just a example,not real).
On Sunday 16 June 2002 14:12, alex wrote:
I'm running a NAT'ed firewall on my gateway box and recently I've
been having problems with the connection chocking and I have been
unable to ssh onto the box to see what was going on. I think (as
I've not got loads of memory) its probably due to the
Balazs Scheidler wrote:
Hi,
I was wondering what the reason is for NAT not rerouting modified packets?
If anything important is modified by a mangle rule that affects routing,
the routing decision is automatically redone as this code fragment shows:
[snip]
This is done only in the OUTPUT
Balazs Scheidler wrote:
But what happens when you initiate a connection on the host running
netfilter, thus you have no PREROUTING chain?
You have the OUTPUT chain.
If I'm doing SNAT in POSTROUTING, the routing decision is not redone, thus
it leaves with the specified source address, but
What kernel version are you compiling?
On Friday 28 June 2002 00.55, Feri adam wrote:
i get error in compile time
here it is
PLZ TELL ME WHAT SHOULD I DO THEN ?
make -C ipv4/netfilter modules
make[2]: Entering directory
`/root/linux/net/ipv4/netfilter'
gcc -D__KERNEL__
On Saturday 29 June 2002 11.46, Patrick McHardy wrote:
A CONNMARK patch will follow but currently CONNMARK doesn't apply
clean against 2.4.18/2.4.19-pre10 ..
Note: There is two versions of the CONNMARK patch. The one in extra
applies if you are using the new_nat patch, the one on old_nat if
Jozsef Kadlecsik wrote:
- rewrite the IPT_CONTINUE targets as matches
I am not very fond of this.. besides the order dependency it also has the
question on how to easily determine what will happen with the packet.. No
obvious distinction between something that matches packets and something
http://www.netfilter.org/downloads.html#cvs
Gilion Goudsmit wrote:
Gents,
I'm trying to checkout from the new CVS, but it's not working:
--
[root@localhost src]# cvs -d:pserver:[EMAIL PROTECTED]:/cvspublic
login Logging in to :pserver:[EMAIL PROTECTED]:2401/cvspublic
CVS
+++ patch-o-matic/pending/conntrack.patch.help 1 Jul 2002 13:32:29 -
@@ -1,4 +1,4 @@
-Author: Marc Boucher [EMAIL PROTECTED]
+Author: Marc Boucher [EMAIL PROTECTED], Henrik Nordstrom [EMAIL PROTECTED]
Status: Works For Me.
This is a general conntrack match module, a superset of the state match
On Monday 01 July 2002 20.46, Michael Shuey wrote:
First, why would I want to SNAT locally originating packets?
Second, are you telling me that netfilter _does_ check to see if a
port is locally bound before using it for a translation?
Mainly in case the locally selected port is already in
On Monday 01 July 2002 19.49, Don Cohen wrote:
The ESTABLISHED indicates the TCP state, UNREPLIED indicates the
conntrack state. This is a TCP session that has only seen ACK in
one direction, no packets in the other.
Almost related note: The connection is not ASSURED.
I'm having
On Wednesday 03 July 2002 14.41, Fabrice MARIE wrote:
I proposed the last one some time ago. A solution to the ordering
issue is to have two kind of targets:
1- terminal target (ie ACCEPT, DROP, REJECT, jump to chain, etc...)
2- non terminal target (ie TTL, MARK, IPV4OPTSSTRIP, etc...)
The
The recent discussions and Oskar Andreassons work on a iptables
tutorial made me take a closer look into the TCP tracking states, and
I notices a couple of odd things that looks like they may be bugs..
1. What is the use of LAST_ACK? From what I can tell this state can
only be reached if the
On Wednesday 10 July 2002 11.16, Harald Welte wrote:
On Wed, Jul 10, 2002 at 10:00:36AM +0200, Peter Kundrat wrote:
before rewriting dst addr/port), and there is no mangle hook in
POSTROUTING (which would help, since it would be before SNAT).
yes, there is. You must be using a relatively
On Wednesday 10 July 2002 09.10, alex wrote:
I've seen numerous references to percieved problems with default
timeouts and potential DoS attacks on ip_conntrack but I'm starting
to think is possible to ip_conntrack just to miss connection
closures.
It can.. see the archives. Posted a
63 matches
Mail list logo
