On Wed, Mar 20, 2002 at 12:12:24AM +0100, Henrik Nordstrom wrote:
2) the 50080/50443 applications rely on TPROXY framework and uses
nonlocal_bind.
Except that nonlocal_bind do not yet work in TPROXY, does it?
not yet.
Zorp supports HTTPS, but it doesn't encapsulate it into CONNECT.
On Wed, Mar 27, 2002 at 02:56:56PM +0100, Henrik Nordstrom wrote:
Please don't forget UDP.
I won't. I definitely want UDP as well.
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
On Wed, Mar 27, 2002 at 04:17:53PM +0100, Jean-Michel Hemstedt wrote:
On Tuesdayen den 26 March 2002 16.33, Balazs Scheidler wrote:
The user is not capable of deciding whether a certificate presented to him
really belongs to the given server. They simply press 'continue' without
thinking
It doesn't handle currently any of them. Fragmentation can be solved by
defragmenting incoming packets. (they are destined to the local ip stack
anyway)
Defragmentation is defenitely needed for this thing to be used in production.
For experimentation conntrack can be used to
Hi,
I have prepared a work-in-progress patch showing which directions I'm
heading with my transparent proxy patches. Here is a summary of changes:
1) It is now possible to query where a connection was destined. It is using
the method Henrik Nordstrom suggested:
I defined the IP_ORIGADDRS
On Thu, Mar 28, 2002 at 04:02:46PM +0100, Henrik Nordstrom wrote:
Balazs Scheidler wrote:
Where is the possible transparent proxy entries defined? Internally in
TPROXY, or in the host IP stack socket table?
in TPROXY.
I guess this would be the rule table telling what should
On Thu, Mar 28, 2002 at 04:39:51PM +0100, Henrik Nordstrom wrote:
Thanks. Explains it quite well.
So there is yet another state table involved here.
Now I am a little confused. What exacly is it that makes this new state table
better suited for the job than conntrack?
because we don't
On Thu, Mar 28, 2002 at 05:55:25PM +0100, Henrik Nordstrom wrote:
an entry is removed from this table when
1) the socket associated with the entry is destroyed (iff a socket is
associated with an entry)
Ok. So there is integration between the tproxy table and the host IP stack
Hi,
I've encountered another ICMP translation problem in netfilter. This time it
occurs when a process initiates a connection and it is translated on the
same host.
How to reproduce:
Box A -- Box B
192.168.131.124 192.168.131.1
Hi,
I've run into a problem, which causes an Ooops during ip_nat_cleanup_conntrack().
I call ip_nat_setup_info() from my PREROUTING hook (right after conntrack,
and before nat), everything works correctly, NAT is applied to both
directions. The oops occurs exactly when the conntrack entry times
On Thu, May 23, 2002 at 07:03:52PM +0200, Harald Welte wrote:
On Thu, May 23, 2002 at 10:18:23AM +0200, Balazs Scheidler wrote:
Hi,
I've encountered another ICMP translation problem in netfilter. This time it
occurs when a process initiates a connection and it is translated
Hi,
Last week I reported an ICMP translation problem, which occurs if the
connection is initiated by a local process.
I now further investigated the problem, it doesn't occur:
* if the NAT box is a gateway, and the connection is initiated on another
box.
* if the connection is not initiated,
On Mon, May 27, 2002 at 12:32:32PM +0200, Balazs Scheidler wrote:
As SNAT happens at NF_IP_POST_ROUTING, reply translation will be performed
at NF_IP_PRE_ROUTING. The following DEBUG output shows what happens (enabled
DEBUGP at the top of ip_nat_core.c):
icmp reply translation, ct=c3617480
Hi,
I've posted a patch against the ICMP NAT problem I encountered, and there
was no reply. It was under the topic Re: addendum to ICMP translation
problem [PATCH] it was posted 27th May.
Could you please review it?
--
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E
On Thu, May 30, 2002 at 03:24:01PM +0200, Harald Welte wrote:
On Thu, May 30, 2002 at 10:39:06AM +0200, Balazs Scheidler wrote:
Hi,
I've posted a patch against the ICMP NAT problem I encountered, and there
was no reply. It was under the topic Re: addendum to ICMP translation
problem
Hi,
Sorry to disturb you again with my transparent proxy efforts, but finally
after my third complete reorganization, things seem to work fine, without
_any_ core TCP changes.
I have a couple of problems though, which all involve core TCP code patches,
and so I would like some advice on the
Hi,
Suppose you have a TCP session, which is transparently redirected to a local
proxy. With the current state of the tproxy framework one need to add two
rules to iptables:
- one to the tproxy table to actually redirect a session
- one to the filter table to let the NATed traffic enter the
On Tue, Jun 04, 2002 at 05:14:47PM +0200, Henrik Nordstrom wrote:
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
Hi,
First of all, thanks for the feedback on my tproxy patches. It generally
works well for TCP based connections, what I'm up to now is proper support
for UDP.
The problem with datagram based protocols is that connection tracking (at
least in my case involving Zorp) and address translation is
On Wed, Jun 05, 2002 at 11:48:49AM +0200, Jozsef Kadlecsik wrote:
On Wed, 5 Jun 2002, Balazs Scheidler wrote:
* yet another flag to ip_nat_setup_info() to set up a single manip only.
* free the state associated to UDP packets after the translation was applied.
* instead of setting up a NAT
On Wed, Jun 05, 2002 at 08:53:25AM +0200, Jozsef Kadlecsik wrote:
On Tue, 4 Jun 2002, Balazs Scheidler wrote:
Possible solutions:
* use a new state (called TPROXY), which would be applied to all TPROXYed
packets (might interact badly with nat/conntrack).
* have the tproxy framework
Hi,
Yet another request for comments. I promise I'll stop with these soon. :)
So I've mentioned that I need a notification when a socket is closed. As
there are other parts in netfilter which might assign state to sockets
through setsockopt/getsockopt, I wanted to make the close callback as
On Thu, Jun 06, 2002 at 10:31:21AM +0100, Andy Whitcroft wrote:
Somewhat arbritrary, but perhaps calling the callback release would match
its meaning and the calling graph better.
ok, callback renamed to release. My implementation is now in place, and I'm
compiling the kernel right now.
--
Hi,
It is a strange idea I know, but I'd be interested in what the opinion of
the core netfilter developers is on porting the whole netfilter subsystem to
Solaris?
Apart from the technical issues, would there be any problems? Does the GPL
allow this kind of usage? (it would be implemented as a
On Sat, Jun 15, 2002 at 02:55:30PM +0200, Harald Welte wrote:
On Fri, Jun 14, 2002 at 12:47:07PM +0200, Balazs Scheidler wrote:
As long as I am one of the maintainers of netfilter/iptables, I am not
going to do any extra hassle in order to support different operating systems.
This includes
On Wed, Jun 26, 2002 at 12:04:23PM +0200, Henrik Nordstrom wrote:
Balazs Scheidler wrote:
I think I now understand, have my packets marked in local OUTPUT, route
based on that mark, and SNAT based on the marks. Is this the way you
suggested? Hmm.. this sounds reasonable on the programmer's
26 matches
Mail list logo
