Hi,
I'm planning to write a small application proxy and I think it could be good
to protect it with syn-proxy, however this will create a lot of overhead on
the firewall.
client -tcp- syn-proxy -tcp- proxy -tcp- server
Has anyone ever thought to introduce a hook inside syn-proxy ?
A way for
On Thu, Sep 11, 2003 at 12:58:57PM +0200, Ed White wrote:
In the end will have syn-proxy to manage the tcp connection, while
application-proxy talk only with syn-proxy and can change the data, block the
connection or redirect (for example by hostname like apache vhost).
You can already do
On Thursday 11 September 2003 15:00, Daniel Hartmeier wrote:
Let pf do syn proxy in front of the userland http proxy. That means pf
will swallow syn floods and only pass fully established connections on
to the http proxy.
Or, if that's not what you meant, what did you mean? :)
The fact is
On Thu, 2003-09-11 at 23:00, Daniel Hartmeier wrote:
This can be done easily within the logic of the http proxy, just write
one that doesn't open the real server connection immediately, but parses
the the request first. This works for TCP protocols where the client
must first send a complete
On Thu, Sep 11, 2003 at 11:32:28PM +1000, Damien Miller wrote:
On Thu, 2003-09-11 at 23:00, Daniel Hartmeier wrote:
It would be cool if pf (some time in the future) had someway of passing
packets off to to a userspace inspection process before they were put
out on the wire or delivered
Can Erkin Acar wrote:
I have been dreaming of passing assambled streams through
the userland. I have not yet come up with a suitable design though.
I've been probably dreaming too, but I would love to have some kind of
scrub tcp that would reassemble the stream, before forwarding it.
That
So we gain:
1) only 2 tcp connection handled by syn-proxy:
client -tcp- syn-proxy -tcp- server
2) possibility to write filter for application protocol without handling the
connection (no sockets or other part to rewrite).
You have two options to get data from a TCP connection. You either
Daniel Hartmeier wrote:
On Thu, Sep 11, 2003 at 04:49:27PM +0200, Cedric Berger wrote:
3) somehow, a NAT rule is created to make that 2nd connection
originate from the
same socket as the first connection/packet.
*cough* embryonic state *cough*
Googling...
Ok, I see..
All you need
Now about the userland inspection. I wonder if it's not possible with just
what we've now, i.e a using a proxy, RDR and NAT:
1) the incoming connection is RDRed to the inspection proxy
2) the inspection proxy open a new socket / new UDP packet to the real
destination
3) somehow, a NAT
Mike Frantzen wrote:
I've been probably dreaming too, but I would love to have some kind of
scrub tcp that would reassemble the stream, before forwarding it.
That would allow me to easily bypass the PMTU problems for example,
without having to tweak all clients (Win2000 friends will send 1500
On Thu, Sep 11, 2003 at 07:37:44PM +0200, Ed White wrote:
P.P.S. I'm subscribed to the list !
Please do not write me in cc every time ;-)
You can't exorcise the habit, that's what procmail is for ;)
:0Whc: msgid.lock
| formail -D 65535 msgid.cache
:0a:
in-x-dupes
Daniel
Hello all,
I am having a problem with filtering on a vlan aware bridge.
I am wondering if anyone has seen a tcpdump
that looks like the following and what it means. Particularly the part about the rule
-1/0(match).
Sep 11 17:35:33.988497 rule -1/0(match): pass in on vlan16:
hello,
hopefully this is not a millionth repetition of a subject but after
reading the PF FAQ and some of the mail archives i am still confused
about how bridging, NATing and PFing all work together. the exact path
of the packets through the NICs is still a little unclear to me. maybe
this should
vlan6 in that rule doesn't mean vlan number 6, it means the interface
vlan6. that is not neccessarily vlan number 6.
On Thu, Sep 11, 2003 at 06:00:53PM -0500, Eaton, Andy wrote:
It looks to me like I just needed to flush all the rules and start over.
My rules are being parsed ok now. I do
It looks to me like I just needed to flush
all the rules and start over. My
rules are being parsed ok now. I do
have one other question though. Why
wont a rule like the following match?
pass in quick log-all on vlan6 inet proto tcp from
172.16.8.71 to 128.252.21.6 port 135
flags S/SA
Really the only way anyone on this list can help is by providing your
entire ruleset. Until then, most of us will be left in the dark.
-a
On Thursday, Sep 11, 2003, at 17:37 US/East-Indiana, Eaton, Andy wrote:
Hello all,
I am having a problem with filtering on a vlan aware bridge. I am
16 matches
Mail list logo
