newnat has an own talk-conntrack-nat.patch. In the extra directory you can
find the non-newnat variant.
Thanks, but where is the newnat version then? The only talk modules are
these in the extra dir:
talk-conntrack-nat.patch
talk-conntrack-nat.patch.config.in
On Mon, 8 Apr 2002, Takuya Satoh wrote:
newnat has an own talk-conntrack-nat.patch. In the extra directory you can
find the non-newnat variant.
Thanks, but where is the newnat version then? The only talk modules are
these in the extra dir:
You're right and I spread false information,
On Sun, Apr 07, 2002 at 03:48:26PM +0200, Henrik Nordstrom wrote:
On Sunday 07 April 2002 12:07, Brian J. Murrell wrote:
Dynamically inserting/removing rules seems like a big hack, but
not like a solution.
Why? I thought that userspace solutions were _always_ considered
the better
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:
On Mon, Apr 08, 2002 at 11:16:38AM +0200, Harald Welte wrote:
I totally agree. Of course those 'orders' would need to go through some
firewall-admin defined policy, before hitting netfilter/iptables.
If it is indeed possible to do
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 that nearly all readers of this mailing
list
On Mon, Apr 08, 2002 at 03:14:59PM +0200, Nigel Kukard wrote:
hrmmm, ok after trying out tc for the last week i've noticed it is
not even nearly as powerfull as netfilter.
I think the LARTC mailinglist is more apropriate, since it is about
interaction between iproute2/tc and
For anyone interested in the UPnP daemon, I have a (semi) working one up for
download.
It is terribly unsecure, probably unstable, and will need alot of work.
That said, it does compile and run, and allows a MSN Messenger clinet to
both initiated and accept voice and video traffic from behind a
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
Sorry for the double post, but I noticed that my original message ended up
stuck to the end of one of the first UPnP threads, and figured it may be
missed there. I'm not really sure how many people read the archives vs. how
many are actually subscribed to the list, but I figured this might
snip
But this thread is about how we can provide UPnP port mapping within
iptables/netfilter in a sensible manner, not how poor the reality of
Internet security actually is when you do not trust your clients at
all. I say providing UPnP with a adequate level of security for the
scope
As i'm almost finished with my new match (superlimit). I ran into some
strange things. It seams that each time I add a new rule to a table the
entire table is reloaded. Because match-checkentry() for my new match is being
runned once for each existing rule in the table and once for the new rule
On Tuesday 09 April 2002 01:18, Henrik Nordstrom wrote:
But this thread is about how we can provide UPnP port mapping within
iptables/netfilter in a sensible manner, not how poor the reality of
Internet security actually is when you do not trust your clients at
all. I say providing UPnP with
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
16 matches
Mail list logo
