Matt:
That's an interesting firewall log. Two quick questions
spring to mind:
1. The source-IP is 192.0.1.11, the dest is 192.0.1.7, but this
is coming in on the eth0 interface of your firewall. So...
how does your LEAF firewall connected to your WinXP box?
I'm presuming that 19
Eyal:
Heya. The problem adding some ACCEPT rules to allow
one address to work, though, is that these rules must be
inserted into the ipchains input chain *before* the rule
which DENY's the whole range. Else the packet will be dropped
before it gets to the forward chain.
Me, I'm no
Tony:
Heya. Yes, the 10.x.y.z private IP address range is blocked
by the default firewall script that comes with Dachstein. You may
want to try "echowall.lrp" which I built for Dachstein which doesn't
do this. I had the same trouble with the standard Dachstein ruleset,
and before long I ha
George:
I just wanted to point out the obvious:
> Is Bering GNU?
> [snip]
> ...I know asking for doc is a lot, but
> maintaining a file of command lines used to make the binaries
> from source would be an excellent first step.
While I'm no expert, this is a new definition of GN
AIL PROTECTED] wrote:
> Aanhalen "Scott C. Best" <[EMAIL PROTECTED]>:
>
>
> Just gambling here but couldn't a packet coming from the inside
> with an echo request or (probably any data destined for 0.0.0.0)
> provoke this kind off response?
>
> A capture of n
Michael:
Heya. Sorry about that. Paraphrasing a famous beagle,
a ScriptAlias bug in your httpd.conf always appears when you're
in the shower on vacation. :)
Service is up again. Sorry for the delays...
-Scott
PS: These are some strange logs you're seeing. :) I believe
they'
Stewart:
Heya. Unfortunately, you've chosen a difficult application
to start with: FTP is notoriously difficult to get working behind
a NAT'ing firewall. Here's a PDF which explains why:
ftp://ftp.echogent.com/docs/FTP_and_Firewalls.pdf
As you can see, active FTP requires more t
Jabez:
Heya. So you know up-front: I've not installed LaBrea
on my systems here. I like the idea of it, of course, but
haven't done anything about it.
That being said, here's what I see below. Now that
you've opened port-80, it looks like your sh-httpd process
(which I believe is
Jabez:
Heya. As you probably know, that log looks like a
CodeRed worm (an IIS web-server virus from early last year).
It also looks like your firewall is simply blocking this
packet before any other process can see it, including LaBrea.
This seems to me a Good Thing. :)
-Scott
>
> I jus
Tony:
Heya. Sorry for chiming in late, I had a busy weekend. :)
I believe the information about ipmasqadm "bypassing" ipchains is
incorrect. I've always known it to be described as:
http://www.tldp.org/HOWTO/IPCHAINS-HOWTO-4.html
Some nice ascii art there. Quoting from th
Morgan:
Heya. I think you're doing two things incorrectly. First,
you're using "iphains -A input ..." which means to Append the rule
at the end of the input chain. So, it may be appendning it after
rule #41 which is blocking it. You need either use -I to Insert
the rule earlier in the cha
Mike:
Heya. Some thoughts on what you're seeing:
> Apr 18 15:44:50 firewall kernel: Packet log: input DENY eth0 PROTO=17
> 66.147.147.152:520 66.147.147.255:520 L=52 S=0x00 I=64309 F=0x
> T=128(#40)
These are UDP packets being broadcast to port 520 on all devices
on your subn
DJ:
I've updated the advice.txt file at:
www.echogent.com/cgi-bin/fwlog.pl
...so that it correctly reports on these packets that you're
seeing. Quick answer: it's a terribly sloppy type of load-balancing,
not a DNS attack. If the SYN flag were set, I'd be much more worrie
>
> 0 0 ACCEPT 47 -- 0xFF 0x00 eth0
> vpnserverip externalip n/a
> 0 0 ACCEPT 1723 -- 0xFF 0x00 eth0
> vpnserverip externalip n/a
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
Dustin:
Heya. Just a quick check to see if you've told your
firewall to allow those protocol=47 packets to come through.
You got the TCP port=1723 ones for PPTP right, but there's
two pieces to it.
-Scott
> Hello,
>
>I am attempting to replace a 2.9.4 based firewall with Dachstein.
Paul:
Heya. This looks to me like a DHCP reply as well (checkout
http://www.echogent.com/cgi-bin/fwlog.pl to see). I think RFC-1542
indicates that port-68 is where DHCP (aka, BOOTP) replies must sent
*to*, and DHCP servers send them from port 67. Though I bet elsewhere
in your logs, you ar
Greg:
Heya. A quick comment or two to your recent post:
> > Is there a significant performance penalty when using a Celeron or
> > Duron processor vs an Athlon or Pentium. Not just in speed but in in
> > the ability to process.
>
> This is a really broad question. It all depends on what
Brian:
Heya. One caveat to Charles' reply that may be entirely
obvious already: you need to have an "SSH account" on one of the
machines in the remote system in order to setup such a tunnel. So
you can use this method to, say, securely tunnel web access to
weblet running on your LEAF box.
all say to me that if you use VNC over the Internet,
> you should do it through a well-encrypted tunnel. (I'd say the same thing
> for other remote-control apps as well, of course, unless they have good,
> built-in encryption. Generally, I think even most sysadmins are too trusting
Some quick feedback to the security-conscious hyperbole
about VNC that's flown across the list recently. In my experience,
it's not exactly true that VNC has "very little" in the way of
security. Some features it has (and I've used):
1. Via AuthHosts, you can specify which IP addresses a
Morgan:
Hello! Have a look here:
http://www.echogent.com/cgi-bin/fwlog.pl
The IGMP packet you're seeing is coming from your ISP's
router, as it's trying to find other routers directly connected to
it. As the "firewall log explanation script" says, you can safely
ignore a
winnt.private.network winnt
I can see my WinNT Box (at .2) query the DS box
for a reverse-lookup (PTR?) for 1.123.168.192, and I cannot
see that the DH box replying with "pc.private.network".
Hope this helps clarify.
-Scott
On Sat, 9 Mar 2002, Michael D. Schleif wrote:
&g
Heyaz. So I'm using a fairly stock DS relase,
and I've a question about properly setting up dnscache
and my "host" entries in network.conf.
How can I keep my LAN machines from making PTR?
requests to my ISP's DNS when trying to get host names
for internal LAN machines? I've setup
Boyd:
As Charles says, the docs on www.phoneboy.com/faq/0372.html
suggest this is a lot like an IPSec connection. You may want to have
a look at echoWall again, though: it supports both FW1 and IPSEC.
You can enable or disable either of them, see what works.
-Scott
> > One guy behind my
Matt:
Heya. Thanks for the candid feedback. Some replies
to you inline, with gratuitous clipping:
>Let me first say that I like echowall and what you've done with.
> I've said that before and recommended it to others even though I've
> authored my own pfw. Yours is better, more capab
Lonnie:
You can best find echoWall on freshmeat.net. The blurb
there is fairly accurate. :)
http://freshmeat.net/projects/echowall/
cheers,
Scott
On Mon, 4 Mar 2002, Lonnie Cumberland wrote:
> Thanks Scott,
>
> I think that I will now proceed to upgrade my old EigerStein LRP to
> the
Lonnie, Boyd:
Ah, serendipity. :) One email, two answers...
To get a PPTP-based VPN client working from behind a
LEAF/LRP disk, you need to do four things (none of which is
to search the email archives, though that works too ;):
1. Be sure to be using a "VPN enabled kernel". Dac
Anyone ever seen this one before: I shut down my
WinNT server today to see what TCP/IP traffic a Windows
machines makes at powerdown. That is, I was tcpdump'ing on
another LAN member. And I saw this:
03:29:14.553849 192.168.123.130.1853 > 209.73.225.9.80: R
804849242:804849242(0) win 0 (
Scott:
What you type looks correct to my eye. What does your
PPTP client think of it? :)
-Scott
On Tue, 26 Feb 2002, Scott Ecker wrote:
> I looked at echowall.lrp and from it I gathered that I should add the rules:
>
> $IPCH -A input -s 0/0 -d 207.202.240.236/32 1723 -p tcp -l -j ACCEPT
Steve:
The Morpheus homepage (www.MusicCity.com) has a snippet
addressing this rumor. Still nervous? Not nearly enough:
http://www.cert.org/advisories/CA-2002-04.html
Remember: your only paranoid if it turns out that everyone
is, in fact, *not* out to get you.
-Scott
>
>http:
Lonnie:
Hello! Yes, that's the idea. No, I've not tested
it. Perhaps you can? Port-445 is "Microsoft Domain Service",
I believe. I saw it once in a tech-support document on
their site.
-Scott
> So you can now have Windows client connections from outside the LRP
> to your Samba server in
Lonnie:
Heya. Here's what I put into the SMB section of the
echowall ruleset:
#SMB#$IPCHAINS -A input -s 0/0 -d $IP_EXT/32 135 -p tcp -j ACCEPT
#SMB#$IPCHAINS -A input -s 0/0 -d $IP_EXT/32 137:139 -p udp -j ACCEPT
#SMB#$IPCHAINS -A input -s 0/0 -d $IP_EXT/32 139 -p tcp -j ACCEPT
#SMB#$IPC
Brian:
Heya. not sure if you knew, but there are 2 or 3 other
steps to getting an IPSec VPN client working from behind a
Dachstein firewall/router. Just holler if you'd like the gory
details.
As for the firewall rules...what you write is close,
but a bit off. Have a look in the ec
Scott:
Heya. Yes, you can port-forward a PPTP VPN connection pretty
easily thru a Dachstein firewall. It comes with a "VPN enabled" kernel,
so all you'll need to do is to uncomment the pptp masq module in
/etc/modules (the line which reads ip_masq_pptp), and tweak your
firewall rules. Back
Dave:
Heya. Give the echowall.lrp package a try. It's got a
more aggressive "don't log this sort of noise" section to it
than the stock firewall that comes with Dachstein does.
EchoWall was built for Dachstein, so it should sneak
in nicely. The README has all the details of install
Stephen:
Heya. Presuming that you're using one of the Dachstein
versions, you need to do 3 things to get "passthru" IPSec
masquerading to work:
1. As Charles said, you need to open UDP-500 and protocol (not
port) 50.
2. You need to uncomment the "ip_masq_ipsec" line in /etc/modules,
Mike:
Heya. Nope, nothing's wrong with your setup; you're
not seeing a bug. You really are seeing all of these deny'd
packets. Someone on your cable subnet may be trying to
crush you with noise, or someone from anywhere on the planet
may have taken interest in your ISP's cable system. No r
Julian:
Hello again! Wow, you have some interesting log files. :)
> I keep getting connection attempts on tcp port 21 from this particular
> IP address. I'm pretty sure this is someone trying to connect to an
> FTP server on my network. Incidentally, there are no FTP servers on my
> LAN
Johansson:
God dag!
Another suggestion that might be easier for you: you
could install a "websitting" application on your son's PC
directly, rather than on the firewall. The Kidnet Explorer
for the PC comes to mind, as does SmartBlock and Filtergate.
Also, depending on how
Julian:
Heya. I'm going to go with what fwlog.pl is telling
you on this one. :) The reply does indeed look to be from the
"NAT router" you had previously at 192.168.254.254. There's
no SYN flag set, so it's not a Code-Red packet, and it's
coming at you at a very high port number (61000+)
Greg:
Heya. I know how you feel about being reluctant to touch
your firewall now that it's running. Fortunately...it's not as
bad as you might remember -- I had to get Dachstein up and running
so that I could get echoWall debugged on it. Since Charles did
both distro's, they look&feel ver
Ed:
Heya. The "3D"'s in what you wrote threw me. Ah, the
horror of HTML email. :)
Try this: head to "www.echogent.com/cgi-bin/fwlog.pl"
and plug in the packet you're seeing:
Jan 14 01:00:32 firewall kernel: Packet log: input DENY eth0 PROTO=1
192.168.101.1:0 24.138.23.131:0 L=84
Greg:
Heya. You got three options to fix this; used to kill me
too. First, you could upgrade your EigerStein box to a Dachstein
one. The Dachstein series puts log files on a separate ram-disk
partition, so even if that disk fills up, the router still works.
That will keep you runn
too tricky.
Good luck!
-Scott
On Mon, 14 Jan 2002, Scott C. Best wrote:
> Eric:
> Heya. My wife connects to her corporate VPN server in very
> much the same way. Yes, it's true: I keep echoWall well-maintained
> because she makes me. :)
> Give echowall.lrp a t
Eric:
Heya. My wife connects to her corporate VPN server in very
much the same way. Yes, it's true: I keep echoWall well-maintained
because she makes me. :)
Give echowall.lrp a try. I do not think you need to install
ipsec.lrp into your firewall: that will connect your entire home
Jim:
Heya. Sorry for the late reply; didn't get to my
mailing list email this weekend.
Yes, echoWall supports both IPSec and PPTP VPNs,
either in passthru mode or as VPON endpoints. See the
.conf file that comes with the echowall.lrp for an example
of IPSec passthrough. To make en
Joe:
Heya. Not to tout too much in the same day, but you
should give echoWall a try. :) It has a more aggressive "don't
log this junk" section than the stock firewall that comes
with EigerStein. It also has support for IPSec of course.
If you can't upgrade due to your production c
Joris:
Heya, sorry for the late reply. You may want to give
the echoWall firewall config script a try (echowall.lrp). It
has built-in support for DIRECTX and MSN gaming. It works on
Dachstein, and might be a bit easier to setup (it has all
the port numbers in there already).
Hope
Jim:
Heya. Your captured packet looks to be a syslog packet
that some firewalls can be setup to broadcast. That is, when
a PIX (for example) firewall sees an event that worries it,
it can log the event and then broadcast to a "syslog collector"
like the one from Kiwi Software (www.kiwisysl
Wyatt:
Heya. Interesting question. I think the best way to
compare and contrast the different firewall-setup packages
is to ask the authors what their intent was for providing it.
I know I built echoWall with a "target user" in mind, and
if you're the target user, and you're not intereste
Heya sport fans. Sorry for the delay...took a
few days off grieving the loss of my first floppy. :)
Echowall is now rev'd to 1.40, and the old
problems with 1.33's use of "cut" has been fixed.
It also fixes the problem of killing off all copies
(and not just one) of "ipfwd" in th
Heyaz. Just a head's up: now that Dachstein has
its "cut" utility fixed, the echowall scripts aren't
working in a few places. I'm working on repairs now; I'm
skipping the quick fix, as I still want it to work back
to ES2B.
Also, the answer is 27 months. :) I first started
with LR
Paul:
Heya. Notso left field, really. I've used ipfwd to
forward IPSec packets (protocol 50 and 51) to my NAT'd LAN's
broadcast address...and IPSec clients on that LAN can handle
it.
Of course...IPSec has some sense of "state" of a
connection beyond just the packets. Webservers do
Jan:
Some interesting packets there in your logs; I've
a better idea now of what @Home is like in the Netherlands. :)
Please give the echowall.lrp package a try. It
logs a lot less of this noise by default. It works fine on
the Dachstein images.
Also, gives this a try:
John:
Heya. Regarding your firewall troubles, might I suggest
that you please give the echowall.lrp package a try, available
at ftp.echogent.com. It's expressly designed towards making an
Eiger/Dach firewall with port-forwarding as easy as possible to
setup.
In other words, it's m
Richard:
Heya. I'll update the fwlog.pl processor at echogent.com
so that it offers some advice about packets like these.
Charles' advice about how to handle them is good, but
I don't think it goes far enough. Here's the "reduce my log
noise" from the echowall.rules file. Please n
put -i $IF_EXT -b -s 224.0.0.0/4 -j DENY
$IPCHAINS -A input -i $IF_EXT -b -s 240.0.0.0/5 -j DENY
$IPCHAINS -A input -i $IF_EXT -b -s 248.0.0.0/5 -j DENY
On Sat, 1 Dec 2001, Michael D. Schleif wrote:
>
> "Scott C. Best" wrote:
> >
> > Heya. Thanks for the pa
Michael:
Heya. Thanks for the packet log, am updating fwlog.pl
to include an awareness of protocol 88. It knew about regular
IGRP (IP protocol 9) but not this one. :)
Regarding silent deny's...you can block the whole
224.0.0.0/4 range (RFC-1112 Class-D multicast) without worry.
T
Lynn:
Heya. Late suggestion: try either the echowall.lrp package,
or cut&paste from the end of the echowall.rules file inside of
that package. I built echowall for a 486 with only 16M of RAM
that firewalled me from a cable-modem environment. As you prolly
know, I had to reboot every week
Troy:
Hello! I agree with Ray: my advice on the fwlog processor
is incorrect. Okay, misleading. :) The parser on the processor is
very much like how ipchains works: it checks the packet against
a chain of rules, and the first one that matches is applied. Your
ident packet log wasn't recogn
Paul:
Heya. Keep in mind that every port-forwarding rule
requires an associated rule which opens the hole in the
firewall in the first place. So you'll need a rule which
looks something like:
ipchains -A input -s 0/0 -d 123.234.123.234/32 80 -p tcp -j ACCEPT
Note that this rule
David:
Heya. You need to use the "ipfwd" utility to forward
arbitrary IP protocols, like the ones associated with VPN'ing.
I'm pretty sure it's still included by default on the Dachstein
images. You can peek in the IPSEC portion of the echowall.rules
file in the echowall.lrp package for e
Scott:
Heya. Sorry for the late reply; I hadn't yet seen
one to your post, so I thought I'd chime in:
> Is there a way to prevent logging of certain events? Someone on my subnet
> is requesting DHCP packets constantly and it's filling up my logs quickly.
> Is it possible to still deny th
Don:
Heya. Easiest thing to do is grab the echowalll.lrp
package and setup your IPSEC_HOST as per the instructions in
the README.
To answer your questions...yes, Dachstein (and the others)
can "masq" and "forward" an IPSec connection much like any other
sorta connection *provided*
Robert:
Heya. In general...an open port on your firewall is
not really a security problem *if* there's no service actually
listening to that port. So, is Dachstein actually running a
service that's listening to UDP port-9?
Secondly, AFAIK, the default firewall rules for
Dachstein
Kory:
Hello again. Quick suggestion:
> Kory Krofft wrote:
>
> All this talk about the weblet message logs has me wondering. My
> firewall log states that since yesterday I have almost 3000 denied or
> rejected packets. I included a sample of the log entries below. Can
> someone please e
Heyaz. Thanks to Kory Krofft's help with the Quake
server testing, I've updated the echowall firewall config
package to 1.33. It's available in the usual places:
ftp://ftp.echogent.com/EchoWall/echowall.lrp
http://leaf.sourceforge.net/devel/sbest/echowall/
http://freshmeat.net/projects/e
Kory:
Just for completeness...the echowall packages does
support FTP servers, both active and passive mode. There's
a whole section about it in the README file.
And *these* are tested. :}
cheers,
Scott
On Sun, 4 Nov 2001, Kory Krofft wrote:
> Thanks,
>
> I will try it out later
Kory:
Wow, I bet this turned into a whole lot more than you
were expecting. FWIW, posting the firewall packet log was the
*exact* right thing to do.
Try this. Change the whole QUAKE section of the
echowall.rules file to look like this:
#QUAKE#$IPCHAINS -A input -s 0/0 -d $IP_EXT
Wire very often, insisted
on this one. :)
Hope it proves useful! Feedback welcome.
cheers,
Scott
On Sun, 4 Nov 2001, Scott C. Best wrote:
> Kory:
> Well, how 'bout that. These lines are causing the
> trouble in Dachstein:
>
> > $IPCHAINS -A input -i !lo
Kory:
Well, how 'bout that. These lines are causing the
trouble in Dachstein:
> $IPCHAINS -A input -i !lo -s 127.0.0.0/8 -j DENY
> $IPCHAINS -A input -i !lo -d 127.0.0.0/8 -j DENY
Turns out it needs a space between the "!" and the
"lo". ES2B (what Dachstein is replacing) didn't.
Kory:
Heya. Interesting error; I've not run echoWall on a
Dachstein kernel yet, but I'm surprised it wouldn't slip right
in. Huh.
The "weird character" warnings appear to be generated
by these two lines in echowall.rules:
$IPCHAINS -A input -i !lo -s 127.0.0.0/8 -j DENY
$IPCHAINS
David:
Heya. What Todd said is pretty much my understanding as
well; NetMeeting is a disaster of a protocol in so far as how
it interacts with NAT'ing firewalls. In addition to all of the
problems Todd mentioned, I believe that the source-IP of a
NetMeeting client is embedded within the d
Heyaz. I've posted an update to echowall, now
version 1.31. Fixes are:
1. Repaired Half-Life specifics (thanks Dan!).
2. Repaired Samba specifics.
3. Repaired "echowall scan" so it reports only the LAN,
not the WAN.
Available in the usual places:
ftp://ftp.echogent.com/Ech
Clark:
Heya. Yeah, all that reading can get tedius. :)
Quick emphasis to your point number 4: to get passive-mode
FTP working, you need to coordinate which ports your FTP
server will propose to a client, and which ports your
firewall will forward along to the server. This is addition
to c
Clark:
Heya. You're running headlong into the difference
between how NAT'ing firewalls act in regards to active and
passive mode FTP. I wroteup a PDF which spares few details
about it:
ftp://ftp.echogent.com/docs/FTP_and_Firewalls.pdf
The end of that document describes ho
Jason:
Heya. I hadn't seen a reply to your post yet, probably
because your question was a bit scary. :) Asking how to open
40,000 UDP ports on a LEAF list would be like asking "how can
I be sure to poison myself?" on a medical self-help list. :)
Anyhow. Presuming you meant to open
Mark:
Okay, so the server allocates the correct IP address,
that's a start. Can I ask though: from the LEAF firewall box,
can you ping this 192.0.0.0 machine successfully? Perhaps you
just meant that IP address as an example, but perhaps not.
Also, importantly, type this after yo
Mark:
Hope your HL problems are getting better. Two quick
thoughts:
> Thanks for the replies...I believe the problem lies in the CStrike
> server config, since this is where the 169.254.0.0 address shows up.
> When try to run a server on another machine without a WAN adapter...it
> shows
Mark:
Heya. This sounds like it's either an interface problem,
or a problem with the CounterStrike server setup. In echowall.conf,
did you choose "ppp0" or "eth0" for IF_EXT? For PPPoE, I believe
it should be the first one.
The 169.254.0.0/16 address you speak about is actually
wh
Rob:
Hello! Yes, you got that right:
> What I have done is at the bottom of the echowall.rules file before
> #lastrule#... put the following
> line; is this correct?
>
> $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 53 -p tcp -j DENY
That should do it, yes.
> Second, can anyone sh
VPN. Thanks!
-Scott
On Fri, 6 Jul 2001, Scott C. Best wrote:
> Vance:
>
> You also forgot to mention how many IP addresses you
> have. :) Okay, I'll assume one. Try this:
>
> 1. PPTP uses GRE packets (protocol 47) and TCP packets (protocol 6)
>to port 1
Vance:
You also forgot to mention how many IP addresses you
have. :) Okay, I'll assume one. Try this:
1. PPTP uses GRE packets (protocol 47) and TCP packets (protocol 6)
to port 1723. The GRE packets are forwarded across your
firewall with the ipfwd command, the TCP packets use the
Vance:
Hard to say. Obviously, you can connect multiple clients to
a VPN server if it's only one at a time: just switch the settings to
show who should be connected, and re-start.
But I suspect you're asking about doing it simultaneously.
This is tricky. In fact, I suspect it's not
Kevin:
If you want...just stick 'em in section 11 of
the echowall.rules file. That'll do it.
-Scott, working on a rev...
On Thu, 5 Jul 2001, Kevin wrote:
> Thanks Scott
>
> I even fired up Echowall and still had my log files go out the roof
> with those dang packets
>
> I will se
Kevin:
Heya. Sorry for the late reply: as you can see in the
archives, there was a big discussion regarding unsolicited TCP
packets to port 53. Intentionally misconfigured packets, too,
ones set with both the SYN and ACK flags, as if your firewall
tried to initiate a connection. Your fi
Michael:
Have you given echowall a try? It supports both
PC-Anywhere and VNC pretty easily. I ask because it sounds
like you've got the right firewall rules (ports 5631:5632,
both tcp and udp) but maybe not the right port-forwarding
rules?
Worth asking...
-Scott
PS: BTW, VNC is
Alan:
Sorry, thought I mentioned that part: echowall.lrp is
available either at the LEAF home page (version 1.22 is the
latest) or here:
ftp://ftp.echogent.com/EchoWall/echowall.lrp
You can also find it on Freshmeat.net (my usual first
starting point).
Also, to cl
Ricardo:
Yes, I know FreeSWAN (IPSec) has been packaged for LRP, and
I believe that PopTop (PPTP) has as well. The intructions for doing this
are far better than my own; point yourself here:
http://lrp.steinkuehler.net/Packages/ipsec1.5.htm
Good luck!
-Scott
At 1:01 PM -0700 7
Rob:
Heya. Some quick answers (am posting this on-list, as
you suggested)
1. Actually, echowall is the one doing more filtering, not less. Charles'
default script lets many of the broadcast-noise stuff go thru to the
end, where it gets logged by the last "catch and log everything that
mad
Alan:
Heya. So...from looking over Intelispan's website,
it looks as if their "Secure VPN Service" is an IPsec one.
In order to have your LRP box support a VPN client, you'll
need to be using a VPN-enabled kernel. Fortunately, that's
not all that hard to do:
1. Got to Charles' site at:
Rob:
Heya. Glad to here the multicast rules flew. Regarding
echowall and ES2B playing nicely together, I built echowall
on and for that system specifically. So, when it installs
itself, it gently brushes aside the default firewall of ES2B
and puts itself in place instead. When/if you de-i
Rob:
Heya. Victor's answer is spot-on:
> > Jul 1 00:44:38 pdrtr kernel: Packet log: input DENY eth0 PROTO=2
> > 192.168.100.1:65535 224.0.0.1:65535 L=28 S=0xC0 I=0 F=0x T=1 (#9)
>
> These are multi-cast packets, possibly from your ISP or a misconfigured
> clown on your cable network
Vince:
Hello! Sorry for the late reply. Try this: setup
echowall to use DIRECTX and NETMEETING to the machine you
want to MSN file-transfer and voice-support support on.
That should do it, but I'll investigate further to see
if there's a simpler setup...
-Scott
> Any plans to add rules
Kevin:
Not so sure about the first question, so all I can
offer is an educated guess:
> I have 32 meg ram in a p2 75 mhz box with two floppy's. I have the ram
> disk set up for 16 meg at the present time.
>
> Does LRP need the other 16 meg of memory to run the programs or do they
> run
suppose (and assume,
> I know its dangerous), that if I were using DHCP, something
> would have been broken?
>
> Thanks again!
> Chris Kulish
> - Original Message -
> From: "Scott C. Best" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <
Phew, busy day. One real bug found in echowall,
now fixed. Also, MSoft updated their DirectX from version
7 to version 8, and the new version (gasp) doesn't use
all of the same ports as the others. I know, I was
terribly shocked myself. Almost fell down.
So, version 1.22 of ech
Chris:
Glad to here it's working fine, but these errors
at reboot make me squirrelly:
> > .Warning: wierd character in interface '!lo' (No aliases, :, ! or *).
> > Warning: wierd character in interface '!lo' (No aliases, :, ! or *).
> > ../sbin/ipchains: host/network '67' not found
> > Tr
Kevin:
Hurm. First...I've never tried Echowall on Ken's PPPoP
image, nor on ESB3. I can see that I should!
Could you email to me a copy of your echowall.rules
and echowall.conf file? That'll help a great deal. Might
want to send it offlist...
Thanks!
-Scott
> If I foll
Chris:
Hello again...
> I am trying to get echowall running on an Eigerstein 2BETA day
> 5/27/01. So far, this is what I have done:
>
> 1. Got echowall.lrp on my disk
> 2. Added echowall to Syslinux.cfg
> 3. Executed ./echowall install from its directory and rebooted
I gotta
1 - 100 of 112 matches
Mail list logo
