On Sun, Jan 13, 2002 at 11:25:41PM -0800, Crist J . Clark wrote:
On Sun, Jan 13, 2002 at 11:56:36AM +0100, Andreas Klemm wrote:
I found a document describing a firewall design only using natd
for redirects to internal network resources. (Hi Marshall, therefore
Cc: to you, since its yours
On Mon, Jan 14, 2002 at 09:40:23AM +0100, Andreas Klemm wrote:
On Sun, Jan 13, 2002 at 11:25:41PM -0800, Crist J . Clark wrote:
On Sun, Jan 13, 2002 at 11:56:36AM +0100, Andreas Klemm wrote:
I found a document describing a firewall design only using natd
for redirects to internal network
Hello
IPSec Tunnel security is working like this: You have to permit traffic to
the Tunnel, this you can du with Access-Lists on a Firewall (ie ipfw)
In the Tunnel, only permitted traffic will be transmitted, so you don't have
to filter packets comming from the IPSec Tunnel. It's not
Hi All,
I have one question? If we have a FreeBSD box configured as a router and
we are not supporting a DHCP like protocol then do we drop packets with
0.0.0.0 source address? As per RFC 1812 we must.
Regards
Kshitij
_
Do You Yahoo!?
Hi,
I don't think this is quite correct.
The fact that I have a tunnel means I have some relation with the other
network, and that I do not trust the network(s) between us.
It does NOT mean that I trust their security setup and want to receive any
packet that they send me.
So I would
Hi,
If you have a IPSec packet you can't see the data(even if u can it's
useless as it's encrypted). unless you exchange keys and know what the
encryption algorithm we can't decrypt and know the information being passed.
Hence, the fact that we are using IPsec gives greater security than any
an anyone point me to some sample mpd-netgraph (3.3) configurations for
Microsoft PPTP clients...
using encyption... for all win98 up to win2k?
i'm using (with pptp0 up to pptp4, say)...
pptp0:
new -i ng0 pptp0 pptp0
set iface disable on-demand
Hi,
I'm not worried about people modifying the IPSec packets en route, that's
what we have strong crypto for.
I am worried about giving the network at the other end of the tunnel full
access to mine. In only a few of the many possible IPSec implementations do
both ends of the tunnel follow the
The problem, of course, is that tunnel-mode IPSEC is too coarse a
mechanism to implement security policy for some people. Imagine if
you will that you're using IPSEC in an extranet situation; that is,
to secure communication between two different parties. Perhaps between
you and your
oops - sounds liek MPPE encryption is a subprotocol of the compression
protocol... hence the confusion!
t
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tariq Rashid
Sent: 14 January 2002 13:54
To: [EMAIL PROTECTED]
Subject: mpd-netgraph PPTP and MS
Hi all
Ok, at this time I would handle this problem like this:
Connect the two sides with an IPSec Tunnel and write an access-list with
ipfw that allow only the specified traffic from the other side network to
your network. This would be the fastest way to handle this problem. For
this, you
And before you suggest that the gif tunnels seen in all those IPSEC
examples actually have anything to do with IPSEC tunnels, please try
it and look again. It's completely uninvolved other than introducing
a route as a side-effect.
I'm not sure what you mean here, but shouldn't the
Blaz Zupan wrote:
And before you suggest that the gif tunnels seen in all those IPSEC
examples actually have anything to do with IPSEC tunnels, please try
it and look again. It's completely uninvolved other than introducing
a route as a side-effect.
I'm not sure what you mean here, but
He was referring to using gif tunnels together with IPsec tunnel mode
SAs (are you?) This works but precisely because of the side effect
that Louis mentioned. A clean solution would user *either* IPIP tunnels
(i.e. gif devices) and IPsec transport mode *or* IPsec tunnel mode (and
no gifs).
Kshitij,
As some other people already mentioned: It might be the case that both
ends of the tunnel are not within the same administrative domain. The
connection is secure, this does not mean that the traffic is also so.
A good solution, from my point of view, would be, instead of passing
Gif tunnels are not the samething as ipsec tunnels. For one some ipsec
implementations simply won't work with gif tunnels. Furthermore the
administrative overhead when there are more than a few tunnels is
enormous. It is much simpler to have racoon do some (a lot) of the work
for you. Say,
On Mon, 14 Jan 2002, Terry Lambert wrote:
This is getting way off topic, but here is a business case
illustration.
Are you perhaps doing what the Q/A people at a previous job were
doing, and stress-testing the crap out of a machine on a Gigabit
LAN, at or near wire speeds, when in the
I'm trying to replace our current NT (PPTP) vpn with a FreeBSD VPN
with minimal impact. Is there any way to run a PPTP server using mpd and
have it authenticate against an NT domains (perhaps with PAM?). Or are
there any other packages I can use that will do this?
I am also
Jason DiCioccio writes:
I'm trying to replace our current NT (PPTP) vpn with a FreeBSD VPN
with minimal impact. Is there any way to run a PPTP server using mpd and
have it authenticate against an NT domains (perhaps with PAM?). Or are
there any other packages I can use that will do
On Mon, Jan 14, 2002 at 06:44:07PM +0530, Kshitij Gunjikar wrote:
Hi All,
I have one question? If we have a FreeBSD box configured as a router and
we are not supporting a DHCP like protocol then do we drop packets with
0.0.0.0 source address? As per RFC 1812 we must.
You need to run a
Hi,
On Monday 14 January 2002 19:55, Rene de Vries wrote:
Kshitij,
A good solution, from my point of view, would be, instead of passing
evering thing from an ipsec tunnel, using ip-filter (co, but without
dummyet) on emerging packets. These packets should then have a different
interface
21 matches
Mail list logo
