Re: [leaf-user] XNTPD.lrp How to config?

[Matthew Schalit]

Thitiporn Pornpirunrak wrote:


But then again, you might just read this:
   http://leaf.sourceforge.net/devel/jnilo/butime.html

and consider using ntpsimpl.lrp as it suggests.
Good luck,
matthew





---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] XNTPD.lrp How to config?

[Matthew Schalit]

Hey now.  You're close.

1st off)  Fix you MShaft outlook express to send straight text,
  not base64 encoded, if you want to make life easier for
  people to help you.  Your messege is "encrypted" so to speak,
  and it's pain to revert it.  Ok I feel better, now.  :)
  ...
  Message-ID: <[EMAIL PROTECTED]>
  MIME-Version: 1.0
  Content-Type: text/plain;
  charset="windows-874"
  Content-Transfer-Encoding: base64
  


2nd)  No it didn't update.  If it did, the log file
  would have an entries like this:

Aug 26 17:07:06 yoda in.xntpd[780]: xntpd version=3.5f; Mon Sep 30 16:08:12 BST 1996 (1)
Aug 26 17:07:06 yoda in.xntpd[780]: tickadj = 80, tick = 1, tvu_maxslew = 7920
Aug 26 17:07:06 yoda in.xntpd[780]: precision = 1 usec
Aug 26 17:11:23 yoda in.xntpd[780]: synchronized to 192.5.41.41, stratum=1
Aug 26 17:11:26 yoda in.xntpd[780]: time reset (step) 2.806055 s
Aug 26 17:11:26 yoda in.xntpd[780]: synchronisation lost
Aug 26 17:15:43 yoda in.xntpd[780]: synchronized to LOCAL(0), stratum=5
Aug 26 17:16:15 yoda in.xntpd[780]: synchronized to 204.152.184.72, stratum=1
Aug 26 22:21:57 yoda in.xntpd[780]: synchronized to 209.81.9.7, stratum=1


3rd)  As you can imagine, most of your ntp.conf
  is incorrect for your setup.  There may be
  a crucial missing command.


4th)  So here's on I use on Unix :)
=
# ntp.conf
server clock.isc.org
server clock.via.net
server 192.5.41.41
server 127.127.1.0
fudge 127.127.1.0 stratum 5
driftfile /etc/ntp.drift
broadcastclient no
enable pll monitor stats
disable auth bclient
statistics loopstats peerstats
==


  The first few 4 lines are easy enough to understand.

  The next command, `server 127.127.1.0' is the special timeserver server
  IP address of the localhost internal clock on my Unix box.  I'm not sure
  how you would specify that on a Linux box.  Maybe 127.0.0.1 is what Linux
  uses.  You could find out easily enough by searching the web.  Xnptd needs
  an address for the localclock in case it can't reach the other timeservers
  when your network goes down.  That let's it still keep time.

  The localtimeserver is fudged on the next line, 'fudge 127.127.1.0 stratum 5',
  which defines the localhost clock to be 5 levels less accurate than the atomic
  time servers that define the time worldwide, the stratum 1 severs.   The net
  servers I listed are stratum 1 and stratum 2.  They will be used before servers
  with a stratum > 2.

  The driftfile you know about.

  The 'broadcastclient no' line tells xntpd not to discover other servers
  on your LAN by listening for their broadcasts.

  The enable line is optional and enables various server options
  that I use to gather statistics.

  The disable line disables authentication that uses keys and keyfiles.
  It also disabled broadcast client discovery associations.  Depending on
  the defaults compiled into xntpd, you may need this line, becuase keys
  are a hassle and complicate the initial rollout.

  The statistics line is optional.


5th)  Restrict inbound access to the timeserver port using shorewall.

6th)  Use the ntp.conf 'restrict' lines only once you get everything
  else working right.

7th)  linuxrouter crossposting removed because Dave Cinege sucks ass.

Good luck,
matthew



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] Need help getting Intel PRO/100 S Desktop Adapterrecognized.

[Matthew Schalit]

>> before and after insomd'ing pci_scan.o


Brad Fritz wrote:

Jeff, if you post the exact names of the drivers you tried, where
you downloaded them from, the exact insmod commands you used and
the exact error output



Plus I don't think you need pci_scan.o for any Pro 100s.
Maybe try putting the nic in a different pci slot, or check
your mainboard bios that you're not forcing something odd,
like PnP OS.

matt



---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] Logging question.

[Matthew Schalit]

First I thought: Log tcp packets that have the SYN flag set.
 The SYN flag is only set on the very first
 packet of a new connection from the outside.

   But you said you want to log everything that
   hits your external interface, not just new
   incoming connections.   So maybe write a filtering
   script  that listens on a socket for log file entries
   and filters them if they are the "body".  You can
   set up a listener via inetd and send the traffic to a
   shell script.  Not sure how to get the logging data
   over there, but syslogd.conf sounds like a place to
   start.  If you want to see a similar example, look at
   sh-httpd, or look at the FAQ entry I wrote for UnixWare7:

Good Luck,
matthew



=
10.7) How do I catch someone trying to port scan my Uw7 host?

The curious out there like to scan the ports of publicly available
computers. At times they are trying to attack your system, and you
can run a dummy service on an unused port that'll send root some
email if someone tries to connect to it.

   Let's call the new service we are going to create 'probe.'
   Let's have probe run on port 999, which is unused.
   Let's make a batch file that probe runs called 'etcprobe.'
   Probe will be added with an entry in /etc/services.
   Probe will be started with an entry in /etc/inet/inetd.conf.
   Etcprobe will be stored in /usr/local/bin.

   /usr/local/bin/etcprobe
  +---
  | #!/bin/sh
  | netstat -an | grep 999 | grep ESTAB | mail -s "Probe Alert!!" root
  |

/etc/services
  +--
  |  ...
  |  ...
  |  probe 999/tcp
  |  ...

/etc/inet/inetd.conf
  +--
  | ...
  | probe  stream  tcp  nowait  root  /usr/local/bin/etcprobe   probe
  |

Now apply the changes made to inetd.conf with the kill command. Test that
probe is working by trying to telnet to port 999. You'll get mail to root
in a few seconds.
===



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] Full web pages won't load

[Matthew Schalit]

Cecil Hammond wrote:

I have "installed" the Dachstein router on an old Pentium 75 and most
everything is working fine.  I can ping from one machine to another but
getting on the internet from a client machine is a problem.  I can bring
up a web page but I can only load about a quarter of the page and then
it just stops...




  Sounds like hardware.  Perhaps a cheapo nic, or maybe faulty cables.
Some errors might show up with a

  netstat -i

I'm not sure how to get those using the ip command, though.
But you can get netstat.lrp from the LEAF site.  The problem
could be duplex related, so let us know if you're forcing
full duplex or half duplex and what your network is composed
of (switches or hubs...).

Good luck,
matthew





---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] NOT URGENT hosts.deny

[Matthew Schalit]

Dennis Stephens wrote:

If my hosts.deny file already has

 >> #
 >> ALL: PARANOID
 >> ALL: ALL

Am I gaining anything when portsentry adds full ip addresses, like

 >> ALL: 24.200.64.187

and as far as that goes.  It's a guess on my part if it is portsentry 
adding
those entries.  Just wondering.

Thanks loads...
Dennis S



Whatever line matches first on it's way down
through the file will be used.

If ALL:ALL comes before ALL:24.200.64.187,
then you gain nothing.  But you'll want to
check my math.
Matthew




---
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] Which LEAF for wireless router

[Matthew Schalit]

Tony Cappelli wrote:

All,

Can I get your experienced recommendation about which LEAF to 
> might work best for a very specific application?

Bering would basically be drop in and go,
once you get it customized to your needs.
It's intended for uses like yours and is
mature and well documented.



I am with an ISP in Los Angeles and we have rolled out 802.11b towers 

Unidirectional?  You talk about many people
pointing at it.  Curious what's your SNR at
these cities and what your external antenna
setup would be on the LEAF.




Also, is it necessary to follow the steps 
> outlined by Richard Dale below to get an Orinoco card
> working with Bering LEAF still?


JN will have to tell you if RC4 has the most recent
updates.  I would figure it does.

I use a Orinoco Gold and rc3.  Were you thinking
an ISA PC-Card converter?  That's what I have and
I don't see the need for a pci one.  Are you thinking
pc104 or some small form factor for the router?

matt






---
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] Problems with RC4

[Matthew Schalit]

Lars Kneschke wrote:

Hello hello.



Another problem. /etc/localtime contains garbage. The line in localtime
looks like this for me 
@@.@@UTC@@.@

Bad! :)


I thought one man's Bad was another mans 0110 0111 01100100.
Matt



---
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] Bering & pcmcia_orinoco.lrp - Orinoco_cs updatedversions?

[Matthew Schalit]

Richard Dale wrote:
> Before I go through the pain of setting up an environment kernel to compile
> the orinoco & pcmcia for use with LEAF, has anybody done this and brought
> the Orinoco driver up-to-date?
> 
> I'm having some timeout errors that I tink might be fixed by a later version
> of the module...  I hope.
> 
> Cheers,
> Richard.



I'm using JN's latest Bering orinoco*.lrp with an
Orinoco Gold in an Orinoco ISA/PCCard adapter w/o
any problems.  I don't have any newer driver, though,
Sorry, but maybe someone else can help.
Matt






---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] dnscache vs. dmz ???

[Matthew Schalit]

Michael D. Schleif wrote:

Matthew Schalit wrote:




Please tell me you've added ipchains -l logging to every packet
1)  inbound on dmz nic
2)  outbound from dmz nic
3)  inbound on internal nic
4)  outbound on internal nic
5)  forwarded by any forward rule

and repost the trail of a dns request from the dmz, judiciously snipping
and trimming if you please.



NOTE: I haven't yet figured out how to get the forward/MASQ chain to log
properly.




Working on this post some more...

As far as getting ipchains to log a forward rule, you just
add a -l the same way you do to any other ipchains rule.
That's the way I remember doing it, but I'm running iptables
now, and I can't check to be sure I'm remembering correctly.







Here is the log for czar (64.4.197.69) doing this:
	ping cdw.com
As you know, from previous posts, tinydns-public is on 64.4.197.65 . . .

>

Oct 10 22:59:51 bluetrout kernel: Packet log: input - eth1 PROTO=17
64.4.197.69:32780 64.4.222.157:53 L=53 S=0x00 I=128 F=0x4000 T=64 (#6)


Packet gets in eth1 via input rule 6.





Oct 10 22:59:52 bluetrout kernel: Packet log: output - eth1 PROTO=17
64.4.197.65:53 64.4.197.69:32780 L=85 S=0x00 I=30547 F=0x T=64 (#5)


Packet got logged via output rule 5, but that looks like this:

Chain output (policy DENY: 97 packets, 19677 bytes):
 pkts bytes target prot opt  ifname   source   destination   ports
   50  3496 ACCEPT all  --   eth1 12.248.253.8664.4.197.69   n/a
0 0 ACCEPT all  --   eth0 64.4.197.69  12.248.253.86 n/a
0 0 ACCEPT all  --   eth0 12.248.253.8664.4.197.69   n/a
0 0 ACCEPT all  --   eth1 64.4.197.69  12.248.253.86 n/a
3   292 -  all  l-   eth1 0.0.0.0/064.4.197.69   n/a
^^^
   |
   |
   |
  Will someone tell me please,
  Where's the ACCEPT?








Oct 10 22:59:52 bluetrout kernel: Packet log: input - eth1 PROTO=1
64.4.197.69:3 64.4.197.65:3 L=113 S=0xC0 I=26128 F=0x T=255 (#6)




And you get a host unreachable or port unreachable like
Brad said, but we still need the forward rules to be logged
to see if there's anything else happening.

Regards,
Matthew





---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] dnscache vs. dmz ???

[Matthew Schalit]

Michael D. Schleif wrote:



How about you tell
me what ip tinydns-public is bound to?
  ==>cat /etc/tinydns-public/env/IP

How about what ip is dnscache bound to?
  ==>cat /etc/dnscache/env/IP



# cat /etc/tinydns-public/env/IP
64.4.197.65

# cat /etc/dnscache/env/IP
0.0.0.0





I've not seen 0.0.0.0 used w/dnscache, and I can't
find a reference to it in the djbdns docs.  It looks
like you are asking two services to listen on
64.4.197.64.






what, pray tell, is wrong with the nestat proof, published twice (2x)
and ignored twice?



I saw it, but I couldn't make sense of how you got
there w/o seeing the contents of your IP files.
What you pasted doesn't make sense w/what your IP files
contain.  There wouldn't be a tinydns on 127.0.0.1
according to your IP file.  So something is missing
and I'm sorry if I didn't catch it from your earlier
posts.







root@bluetrout:/root
# netstat -anp | grep dns
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp  0  0 0.0.0.0:53  0.0.0.0:*  LISTEN  28373/dnscache
udp  0  0 0.0.0.0:53  0.0.0.0:*  28373/dnscache
udp  0  0 64.4.197.65:53  0.0.0.0:*  28326/tinydns
udp  0  0 127.0.0.1:530.0.0.0:*  28324/tinydns



Or at least make up something interesting...



are you being cute?  did i miss the joke?



No.  Yes.  I won't joke w/you again.




with some sleight-of-hand, adding the real external_ip (wan1, _not_
tinydns-public ip) and add an ipchains forward rule from dmz to masq'ed
internal dcd interface, then I see the request _get_to_ dnscache and I
see dnscache resolve the name and _send_the_answer_ -- however, nothing
makes it back to the dmz.


You're missing a route.



which one?




You haven't pasted in the entire trail of the dns request
packet as it moves along your network.  So it's not likely
I can narrow down which part of your routing/forwarding
is incomplete.





root@czar:~
# ip route
64.4.197.64/26 dev eth0  proto kernel  scope link  src 64.4.197.69
default via 64.4.197.65 dev eth0

>

root@bluetrout:/var/log
# ip route
64.4.222.158 dev ipsec0  proto kernel  scope link  src 64.4.222.157
64.4.222.158 dev wan1  proto kernel  scope link  src 64.4.222.157
64.4.197.64/26 dev eth1  scope link
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.254
192.168.123.0/24 via 64.4.222.158 dev ipsec0
default via 64.4.222.158 dev wan1




Do you forward and masq from the dmz to internal or just forward?
Have you posted all the rules you're using for that?



this could be it:

	




Ok, I'll have to digest that for a bit.  I've never seen
so many forward rules in one place, and it's a lot.







imho, we are missing some crucial ipchains link from dcd out eth1 to the
dmz -- but, what can it be?


Please tell me you've added ipchains -l logging to every packet
1)  inbound on dmz nic
2)  outbound from dmz nic
3)  inbound on internal nic
4)  outbound on internal nic
5)  forwarded by any forward rule

and repost the trail of a dns request from the dmz, judiciously snipping
and trimming if you please.



quite honestly, this is a very busy network and to log each and every
packet through this router is not a good idea ;<




Well, if you can't define the problem, you'll never
have a chance at solving it.  Someone made the choice
not to have a test bench setup.  That saved them very
little $$ but may cost them a lot of time.





i've avoided going there, unless there is no other way -- which is why i
hoped that somebody had already worked the magic.



If your forward rules were generated by CS's scripts, then
you may get your wish.





perhaps it is a missing masq chain?

until i publish more details, what do you think about what is already
published?



I think it's very easy to make a subtle error in routing,
which in this case arises in the forward/masq rules you
have installed, yes.

on to the other posts..
matt




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] system logs on a bering box

[Matthew Schalit]

Jacques Nilo wrote:

> This issue will be solved in rc4. In the meanwhile check:
> http://leaf.sourceforge.net/article.php?sid=56
> 
> Jacques


Any chance you could  those code snippets 
or whatever the tag's called these days? :)
matt








---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] dnscache vs. dmz ???

[Matthew Schalit]

Brad Fritz wrote:
> On Fri, 11 Oct 2002 09:26:54 EST mds wrote:


> I still think using two instances of dnscache in front of two
> instances of tinydns would be a cleaner solution if you need
> separate DMZ and LAN namespaces.  Otherwise you might end up
> in routing kludge hell getting this to work.




2 instances of dnscache
2 instances of tinydns

are much better than one dnscache imo.  I noticed
that right away when he mentioned it as a goal.
Rung some bells that did.  Don't know why, just
feels icky, heh.


and also along the lines of what Charles said,
is that an ICMP reply from the DNS client of a
problem needs to be quickly tracked down w/tcpdump
on the DMZ.  I'll read your threads and throw
another pair of eyes on the numbers, also to see
if that helps.

good luck,
matt






---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] dnscache vs. dmz ???

[Matthew Schalit]

Michael D. Schleif wrote:
> thank you, for your continued interest . . .
> 
> Matthew Schalit wrote:
> 
>>Michael D. Schleif wrote:
>>
>>>"Michael D. Schleif" wrote:
>>>
>>>
>>>>does anybody have a proxy-arp dmz and also running tinydns & dnscache?
>>>
>>>Anybody have such setup that works?
>>
>>I have three nics in Bering rc3
>>
>>     eth1 10.10.10.0/24 + tinydns private + dnscache
>>  public static eth0  |  leaf  |
>> (Internet)   || eth2 10.20.20.0/24 (dmz)
>>
>>and that works great with both subnets talking to dnscache,
>>which only needed an extra line in /etc/dnscache/env/IPQUERY
>>like this
>>
>>/etc/dnscache/env/IPQUERY
>>
>>   |10.10.10
>>   |10.20.20
>>   |127.0.0.1
>>   |
>>   |
>>   |
> 
> 
> yes, i do this all the time.  we have at least three (3) customers with
> networks with at least two (2) internal networks; and, dnscache/tinydns
> work flawlessly in these environments.
> 
> however, this is a proxy-arp dmz -- a totally different animal -- on
> that i do not fathom inside and out . . .
> 
> 
> 
>>and the rule in /etc/shorewall/rules:
>>   ==
>>  |
>>  | ACCEPT dmz fw tcp 53
>>  | ACCEPT dmz fw udp 53
>>
>>But what's not working, because I guess you tried this?
>>Is it routing or dnscache or fw rules?
> 
> 
> ok, with the default setup, according to:
> 
>   <http://leaf.sourceforge.net/devel/jnilo/dnscache3.html>
> 
> if a dmz name query cannot be answered by tinydns-public, then it just
> times out -- *never* getting to dnscache.


Let's not get me to that point just yet.  How about you tell
me what ip tinydns-public is bound to?
   ==>cat /etc/tinydns-public/env/IP


How about what ip is dnscache bound to?
   ==>cat /etc/dnscache/env/IP


Or at least make up something interesting...





> with some sleight-of-hand, adding the real external_ip (wan1, _not_
> tinydns-public ip) and add an ipchains forward rule from dmz to masq'ed
> internal dcd interface, then I see the request _get_to_ dnscache and I
> see dnscache resolve the name and _send_the_answer_ -- however, nothing
> makes it back to the dmz.


You're missing a route.

Do you forward and masq from the dmz to internal or just forward?
Have you posted all the rules you're using for that?





> imho, we are missing some crucial ipchains link from dcd out eth1 to the
> dmz -- but, what can it be?


Please tell me you've added ipchains -l logging to every packet
 1)  inbound on dmz nic
 2)  outbound from dmz nic
 3)  inbound on internal nic
 4)  outbound on internal nic
 5)  forwarded by any forward rule


and repost the trail of a dns request from the dmz, judiciously snipping
and trimming if you please.

good luck,
matt








> remember:
> 
> root@bluetrout:/root
> # netstat -anp | grep dns
> (Not all processes could be identified, non-owned process info
>  will not be shown, you would have to be root to see it all.)
> tcp  0  0 0.0.0.0:53  0.0.0.0:*  LISTEN  28373/dnscache
> udp  0  0 0.0.0.0:53  0.0.0.0:*  28373/dnscache
> udp  0  0 64.4.197.65:53  0.0.0.0:*  28326/tinydns
> udp  0  0 127.0.0.1:530.0.0.0:*  28324/tinydns
> 
> ideas?



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] Multiple IP addr in Bering.

[Matthew Schalit]

Jeff Newmiller wrote:


M.W.M.:
>>Just put your commands of ip aliasing like this on 
>>/etc/init.d/bootmisc.sh :

J.N.:
> Putting network configuration commands in /etc/init.d/bootmisc.sh is a
> good way to


  1) make a long thread on leaf user :)
  2) make the aliases at a late stage in the bootup
  3) make svi network not work.
  4) make yourself late for dinner naw.


But don't let that stop you from
learning by destruction.  much fun
to be had there.
matt









---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] dnscache vs. dmz ???

[Matthew Schalit]

Michael D. Schleif wrote:
> "Michael D. Schleif" wrote:
> 
>>does anybody have a proxy-arp dmz and also running tinydns & dnscache?
> 
> 
> Anybody have such setup that works?
> 


I have three nics in Bering rc3


     eth1 10.10.10.0/24 + tinydns private + dnscache
  public static eth0  |  leaf  |
 (Internet)   || eth2 10.20.20.0/24 (dmz)



and that works great with both subnets talking to dnscache,
which only needed an extra line in /etc/dnscache/env/IPQUERY
like this

/etc/dnscache/env/IPQUERY

   |10.10.10
   |10.20.20
   |127.0.0.1
   |
   |
   |



and the rule in /etc/shorewall/rules:
   ==
  |
  | ACCEPT dmz fw tcp 53
  | ACCEPT dmz fw udp 53



But what's not working, because I guess you tried this?
Is it routing or dnscache or fw rules?

Matt




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] RE:DMZ configuration problems

[Matthew Schalit]

Ray Olszewski wrote:
> 
> I waited to reply in the hope that someone would offer better advice 
> than I can.


Well that's not gonna happen anytime soon :)
You pretty well helped him through any leaf config probs
he had.  It works now.  just slowly :/



Troy,
Slow ftp means driver/nic/cableing/cable-routing issues.
FTP's one of the best ways to bring a problem to light.
There are thousands of posts over the years to usenet
about ftp slow in one direction or from between some
machines but not all, even a few to this list.

Suggest you use matched nics all around.
All 3com, or all Intel, or all SMC.  Buy
new Belkin CAT5e or CAT6 cables and get
serious if you have a few $$.  Suggest PCI
10/100 nics and leave them to autosense
duplex and linespeed.  Use a switch, but
if you can't, then you'd best have a decent
hub, like a netgear or whatnot.



> 1. Are you dropping a lot of packets at the interfaces? After one of 
> these slow transfers, look at the output of "ip -s link show" and see if 
> the packet counts suggest any problems.


Lord only knows if he'll be able to actually see the framing
errors or something, but it's an excellent thought.





> 2. Is the firewall processing the packets the way it should be?

We can figure it is Ray, unless there's some strage traffic shaping
going on with TC.  Otherwise, it's ACCEPT, DENY, or REJECT.  There'll
be no slowness with those three.




 > Do you make shell
> connections (with telnet or ssh) from the LAN to the DMZ host? 

Excellent suggestion.  An scp would be a very good test.
ls -l may be terminal dependant.



> 5. Are there any problems at the hardware level? 


If he had an IRQ conflict, I'd think that the OS
would freeze up.  That's the usual result, but
linux 2.4 may be different somehow from the way
other OS have historically behaved.

   driver problem ==> a device acts strangely, proceeses may hang, maybe OS hangs.
  Can lead to a bsod or panic.
   port addy problem ==> memory gets corrupted.  procceses eventually fail, which
 gets noticed before the whole OS goes down.  On NT you
 may see a Blue Screen of Death, or the OS may freeze if
 some sensative system process gets affected.  On linux
 you get a kernel panic.
   irq problem ==> two devices try to respond and speak w/the cpu at
   the same time and totally hose the flow of traffic
   on the ISA bus or PCI bus, causing the whole shebang
   to lose all sembalence of logic, and thus the OS freezes.
   No response from keyboard.  No BSOD.  No Panic.
   If the IRQ problem is w/a mouse or keyboard, then the
   mainboard can spontaneousely reboot.


I'm a little rusty at diags, so the above may be wrong.
I haven't written it out in a while.

take care you guys,
matt




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] DMZ configuration problems

[Matthew Schalit]

Troy Aden wrote:
>   This is my first attempt at setting up a DMZ so I am
> admitting now that I probably got it all wrong. That said, I am hoping
> someone on the list can point out where I have made my mistakes and point me
> in the right direction. Here is what I am attempting to accomplish.
> 
> 
>   -> Internet-> eth0 Bering box using shorewall >
> eth1 loc zone
>   
> ---> eth2  dmz zone




>   GOAL IS: 
>   TO ALLOW ALL INTERNET TRAFFIC INTO MY DMZ

What do you mean?  Do you mean that you want to forward
every port on the firewall into the same host on the dmz?
To what host?  Any particular reason?


>   TO ALLOW DMZ ACCESS TO THE INTERNET (BUT TO LOG IT)

I didn't see you taking steps to log this.






>   TO ALLOW LOC ZONE OPEN ACCESS TO DMZ
>   TO BLOCK ALL TRAFFIC FROM DMZ TO LOC ZONE and log it if it
> tries to connect to loc zone.
>   TO ALLOW DNSCACHE AND DHCPD TO WORK FOR BOTH ZONES.
> 
>   I thought I had it all working until I attempted to do an
> ftp file transfer between my windoz systems on the loc zone to my Linux
> server in the dmz zone. My transfer rate was terrible and FTP kept giving me
> a "cannot connect to data socket error". Even attempting an ftp transfer
> from a remote server was failing. 


Ftp clients can transfer files in two modes, active or passive mode,
which determines who initiates the data connection.   Which were
you trying to do, and what's the output of lsmod?




> Please keep in mind that this is my first
> attempt at this and I have tried to follow the shorewall howto for setting
> up three interfaces but I am pretty sure I goofed. 


Doin' purty good so far I reckon.



> PLEASE HELP! I have
> included all the info that I think is pertinent but if you require more
> please let me know and I will provide it. Thanks in advance. 
> 
>   Troy




> #
> # Shorewall 1.3 /etc/shorewall/zones

Is fine.


> # Shorewall version 1.3 - Rules File
> # /etc/shorewall/rules
> # Accept DNS connections from the firewall to the network
> #
> ACCEPTfwnet   tcp 53
> ACCEPTfwnet   udp 53

Well here you figure that it might use tcp and udp,
but not below





> #
> # Accept SSH connections from the local network for administration
> #
> ACCEPTloc   fwtcp 22
> 
> # DENAT all my webserver from web
> DNAT  net   dmz:192.168.2.25  tcp -
> DNAT  net   dmz:192.168.2.25  udp -


Yes I see you letting everything in.  Interesting :)




> # Bering specific rules:
> # allow loc to fw udp/53 for dnscache to work
> # allow loc to fw tcp/80 for weblet to work
> #
> ACCEPT  loc   fwudp 53

Like here you don't have the tcp 53 entry.  You never
know which resolver library will initiate the traffic
and whether it will be tcp or udp.  Best to Accept both.



> ACCEPT  loc   fwtcp 80
> ACCEPT  loc   fwudp 67
> ACCEPT  loc   fwudp 68
> 
> # Bering specific rules:
> # allow dmz to fw udp/53 for dnscache to work
> # allow dmz to fw tcp/80 for weblet to work
> #
> ACCEPT  dmz   fwudp 53

Here too.


> ACCEPT  dmz   fwtcp 80
> ACCEPT  dmz   fwudp 67
> ACCEPT  dmz   fwudp 68
> 
> #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


But you don't have any rules for loc to dmz...
Onto the next file...






> # Shorewall 1.3 - Masquerade file

Is fine.





> # Shorewall 1.3 -- Interfaces File

Is fine also.






> #  /etc/shorewall/shorewall.conf V1.3 - Change the following variables to

Not sure.  Best to hear from T.E. about this.







> # /etc/network/interfaces -- configuration file for LEAF network

That's ok afaik.







> # /etc/hosts.allow: list of hosts that are allowed to access the system.

not an issue w/your ftp.





> /ETC/HOSTS

ok.



> /ETC/DNSCACHE/ENV/IP
> 
> 192.168.1.254
> 192.168.2.254


This I wouldn't do, but rather leave dnscache
thinking it only listens to the 192.168.1.0 network
on eth1 and tell it that you want to allow queries
from all three networks in:

Hub:># cat /etc/dnscache/env/IPQUERY
192.168.1
192.168.2
127.0.0.1


which is what I do and it works, but that's not to
say your way doesn't also.  I think using IPQUERY
is more intuitive but don't understand djbdns totally.





> /ETC/DHCPD.CONF

no comment.  Don't use it.



So you didn't post your shorewall policy file.  That's
sort of important, plus what the right honrable long-hair
RayO asked for (ip addr show, ip route show, lsmod, etc...)
:)

good luck naw,
matthew




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.co

Re: [leaf-user] Virtual interface on Bering.

[Matthew Schalit]

Dmitri Gofmekler wrote:
> Hi,
> 
> What synatx (where to get an example) for creating the virtual
> interfaces on Bering?
> 
> 
> Thanks in advance.


Maybe I'm not up on the lastest lingo, but are
you asking about adding an ip alias to a nic so
that it responds to two networks?  If yes, then
you need to read up on the ip command.

Or are you refering to briding two physical networks
into one virtual network?  If yes, then you'll want
to read up on the bridge.html in jnilo's devel files.

Matt





---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] Issues...

[Matthew Schalit]

James Williams wrote:


> Now on to the problems. The first problem is that the system doesn't 
> seem to be installing the etc package.


Is it listed in syslinux.cfg?  Show us what's
in syslinux.cfg.


> '/bin/bash: 10: Syntax error end of file unexpected ( expecting "}"). 


Is this the type of error, anyone, anyone, that
occurs when a file gets modified by Windows which
changes the CRs to CR-LFs?  Does the user need to
run dtox or perhaps start over bypassing windows?

good luck,
matthew



> Can someone help me?
> 
> James Williams




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] Can't ping

[Matthew Schalit]

Liu Mei wrote:
> Well. Things become better.
> 
> Now the eth0 (the external port) is 192.168.1.113,
> which is assigned by running dhclient.
> 
> The eth1 (the internal port) is 192.168.2.1, which is
> assigned by myself.


Jumping some hoops to run that IP I guess, but
I havent' been following this thread too closely.
Sounds fun




> I can now ping the internet and LAN from my route.
> I can also ping 2.1 from LAN
> 
> But I can't ping the internet from LAN.


See below




> The follows are the things you may want to check
> 
> Please help.
> 
> Kind Regards,
> 
> Liumei





> Chain forward (policy ACCEPT: 0 packets, 0 bytes):
>  pkts bytes target prot opttosa tosx  ifname source
>destination ports
> 4   240 ACCEPT all  -- 0xFF 0x00  eth0  192.168.2.0/24
>0.0.0.0/0 n/a
> 0 0 ACCEPT all  -- 0xFF 0x00  eth0  0.0.0.0/0 
>192.168.2.0/24n/a
> 0 0 MASQ   all  -- 0xFF 0x00  eth1  192.168.2.0/24
>0.0.0.0/0 n/a



Well I don't get why you have the above 3 rules
considering your setup runs on dual private network
segments.  You can see that the MASQ rule never gets used.

I'd think that because your eth0 goes to an ISP/Internet
that you want to MASQ traffic from your internal LAN out
to the net, not forward it unMASQed.

So the first line is doing all the work because it's the first
rule that applies to the traffic in question, and the traffic
is getting moved to go out eth0 unMASQed.

The second line I don't get at all.  Why would you try
to forward all traffic destined for the .2.0/24 network
out of eth0?

The third line is almost what you want, but should read
more like this, I believe, but I've been wrong lately :)


0 0 MASQ   all  -- 0xFF 0x00  eth0  192.168.2.0/24
0.0.0.0/0 n/a
^^^
 |
/
   /
 my changes





And finally


> Chain output (policy ACCEPT: 2 packets, 168 bytes):
>  pkts bytes target prot opttosa tosx  ifname   sourcedestination 
>ports
> 0 0 ACCEPT all  -- 0xFF 0x00  lo 0.0.0.0/0 0.0.0.0/0 
> n/a
> 4   240 DENY   all  -- 0xFF 0x00  eth0   192.168.2.0/240.0.0.0/0 
> n/a
> 0 0 DENY   all  -- 0xFF 0x00  eth0   0.0.0.0/0 
>192.168.2.0/24 n/a




Here you can see that your rules are DENYing any traffic
from getting out eth0 if the traffic came from 192.168.2.0/24.

Well, first you forwarded it over to go out there, but then you
fail to let it out.  Why do that ?  :-)

And now, back to the right honorable Ray O.
Good Luck,
matthew



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] sshd

[Matthew Schalit]

> So, I went to http://leaf-project.org/devel/jnilo/packages/ and loaded
> this package in.  Saved this package, rebooted
> "Now I get Privilege separation use5r sshd does not exit"


That's expected.  It's in the docs somewhere that you
need to make the following additions (the sshd lines)


--- /etc/passwd -
[snip]
mail:x:8:8:mail:/var/spool/mail:/bin/sh
sh-httpd:x:50:10:shell-script web server:/var/sh-www:/bin/sh
sshd:x:51:65534::/var/run/sshd:/bin/false
alias:x:70:65534:qmail alias:/var/qmail/alias:/bin/sh
[snip]
-




== /etc/shadow ==
[snip]
mail:*:10091:0:9:7:::
sh-httpd:*:10091:0:9:7:::
sshd:*:10091:0:9:7:::
alias:*:10091:0:9:7:::
[snip]
===


I think that was all it took, but then again :) 
Matthew




---
This sf.net email is sponsored by: DEDICATED SERVERS only $89!
Linux or FreeBSD, FREE setup, FAST network. Get your own server 
today at http://www.ServePath.com/indexfm.htm

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] sshd

[Matthew Schalit]

Steve wrote:

> got it from the same site.  I have tried reloading several times all
> with the same result.


I forgot this, sorry:

Hub:># lrpkg -i ldd.lrp
Installing ldd ... Done.

Hub:># ldd /lib/libz.so.1.1.4
 libc.so.6 => /lib/libc.so.6 (0x40a13000)
 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x08c0a000)

Hub:># ldd /usr/sbin/sshd
 libutil.so.1 => /lib/libutil.so.1 (0x4b32e000)
 libz.so.1 => /lib/libz.so.1 (0x4b331000)
 libcrypt.so.1 => /lib/libcrypt.so.1 (0x4b342000)
 libc.so.6 => /lib/libc.so.6 (0x4b36f000)
 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4b322000)



I don't see libnsl.  Why don't you ldd sshd yourself and paste
in the output along with the ls -l stuffings.  Matt



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] sshd

[Matthew Schalit]

Steve wrote:
> Date: Sun, 29 Sep 2002 14:15:14 +0200
> To: [EMAIL PROTECTED]
> From: Erich Titl <[EMAIL PROTECTED]>
> Subject: Re: [leaf-user] sshd
> 
> 
>>Steve wrote the following at 08:27 29.09.2002:
>>
>>>I am trying to set up sshd in Bering.
>>>I have loaded the sshd.lrp and libz.lrp packaged and have generated my
>>>keys ,but when sshd is run it complaines that is cannont find
>>>libnsl.so.1 file.  I've done a few searches and can not find where this
>>>file might be or where I can download it from.
>>>Any suggstions?
>>>Regards.
>>
> 
>>Where did you take your sshd.lrp from. I have sshd on bering running
>>on bering without libnsl. IIRC I got mine from Jacques Nilo's packages
>>
>>Erich
> 
> 
> got it from the same site.  I have tried reloading several times all
> with the same result.



Hub:># ls -l /usr/sbin/sshd
-rwxr-xr-x1 root root   678220 Aug  2 13:00 /usr/sbin/sshd

Hub:># ls -l /lib/libz.so.1.1.4
-rwxr-xr-x1 root root61464 Mar 16  2002 /lib/libz.so.1.1.4

Hub:># uname -a
Linux hub 2.4.18 #4 Sun Jun 9 09:46:15 CEST 2002 i586 unknown


That's what my bering rc3 looks like.  How about yours?
Matthew







---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] vpn help, link included

[Matthew Schalit]

Jeff Newmiller wrote:
> On Sun, 29 Sep 2002, Matthew Schalit wrote:
> 
> 
>>In addition to what JO said, I'd put the printer on
>>a Jetdirect and make life easy.
> 
> 
> As someone with a printer with a Jetdirect, I highly recommend having a
> single computer act as print server anyway... spooling performance can
> suck remarkably if you don't.



Thanks for the tip.  I've noticed a slowness w/some printers
that didn't have a lot of RAM when using their builtin NICS
and no Jetdirect.  Is that possibly a factor in your setup?
If it can't dump the print job completely into the printer's
RAM, then it slows down, AFAIK.  Sort of OT, but interesting.

Matt



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] vpn help, link included

[Matthew Schalit]

In addition to what JO said, I'd put the printer on
a Jetdirect and make life easy.  Be sure to include
it's ip addy/name in DNS and /etc/hosts everywhere.
I don't like to rely on a computer as a print server,
but whatever works and saves time/$$.

Is there any NAT going on, and can IPSec handle that?
I think the ESP flavor of IPSEc can, but it looks like
your connecting subnet to subnet, and doesn't that
disallow ESP/NAT?

Lynn was working on an IPSec mini-HOWTO and it's good
stuff.  Oh well.  Not my area really, but I'm rolling
out a host-to-subnet (roadwarrior) that's easier.

Regards,
Matthew





Joey Officer wrote:
> First thing you need to do is to make sure that the workstation on the B
> side can print to the printer.  Once that is done, everything else is a
> piece of cake.  Look over the IPSec documentation, that is what you want to
> put in place.  I have almost an identical setup here at the office, and it
> works fine.  Let me know if you need some specific help.
> 
> BTW, I'm running Dachstein-CD Based installs with IPSec 1.91.  Took me a few
> days to fully understand what it was I was doing, but I've got it down now.
> Atleast that part.
> 
> Joey Officer
> Martin Apparatus, Inc.
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of junkmail
> Sent: Sunday, September 29, 2002 2:02 AM
> To: [EMAIL PROTECTED]
> Subject: [leaf-user] vpn help, link included
> 
> Hello,
> 
> I have what I think would be a VPN task for maybe a LEAF box I have set
> up severl LEAF as a simple firewall and think they are terrific...
> A .jpg is worth a thousand words so... if any of you could point me in the
> right direction and take a look at the layout I have in mind I would be
> greatfull for any suggestions / starting points...
> 
> here is the layout
> http://home.attbi.com/~crackerjack31/help.jpg
> thanks
> Gary.



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] trouble with ipip encapsulation tunnels (well,unexpected behavior, really)

[Matthew Schalit]

Hi Chad,
   Hope things are working out.

   I like your diagram, and then again I don't.
But maybe it's just me, I don't know, but I can't
understand it as much as I need to.  I admire your
attempt, though, because it was properly spaced,
readable, and darn good for what it was.


   But what I need is:
 1) a box symbolizing each router, switch, hub, and host.
 2) then a line into each box for each nic,
 (the line representing your CAT5)
 3) then the ipaddy/mask of each nic written next to the line.
 4) If the internet comes into play, label that too.

   I'll make an attempt to redo your drawing, but plz
fix it and then paste in your syslog trail of the packet
and include   ip addr show
   ip route show
and any other ip tunnel show thing you can think of that's relevant.
Roger.





   172.24.8.???/24
  __  \   __172.24.20.???/22
 |  |||
 |home agent||  LEAF  |,   <--subnet 172.24.20.0/22
 |__||||
172.24.8.99/24 |
   |
   subnet 172.24.8.0/24|172.24.20.104/22
  _|___
 | |
 |foreign agent|
 |  (a host)   |
 |_|
   |  ???.???.???.???/24

   ?
   ?  <--- What's this link, cat5?
   ?
   ?

   | 172.24.8.24/24
   |__
  |   |
  Is this another host?--->   |mobile node|
  |___|



   You said the foreign agent has only one nic.  So it's a computer.
Is the mobile node a differnt computer?  If so, how does it connect
to the foreign agent.  If the link is cat5, then the foreign agent
has to have 2 nics and be a bridge, essentially.

   Maybe the the mobile node is a virtual extension of the foreign
agent, and there's only the computers in the scenario:
 1)  Home computer
 2)  Leaf router
 3)  Foreign computer
Is that what's happening  Well I'll stop for now :)
Plz check the addys/masks and fill in the blanks.

Matthew










Chad Carr wrote:
> On Fri, 27 Sep 2002 08:22:02 -0700
> "Matthew Schalit" <[EMAIL PROTECTED]> wrote:
> 
> 
>>Chad Carr wrote:
>>
>>>Hello routing and tunneling guys and gals!  I have a tunneling quandry
>>>for ye.
>>>
>>>I am doing an implementation of mobile ip and have finally solidified
>>>all of the protocol bits to implement a foreign agent, and have come
>>>to the part where I need to accept ip-in-ip tunneled packets for a
>>>mobile node, detunnel them, and deliver them to him.  I am using the
>>>kernel ipip.o module for this, and have configured the tunnel as
>>>follows:
>>>
>>>__ _  ___
>>>   |  |   | ||   |
>>>   |home agent|===(router)===>|foreign agent|--->|mobile node|
>>>   |__|   |_||___|
>>>
>>>
>>>home agent ip- 172.24.8.99
>>>foreign agent ip - 172.24.20.104
>>>mobile node ip   - 172.24.8.24 (on the foreign network)
>>
>>
>>
>>I question the ip addresses below
>>
>>
>>
>>
>>
>>>I am not in control of the home agent, but I have verified with a
>>>sniffer that he is sending me well-formed ip-in-ip packets for the
>>>mobile node, plus he works with anothe foreign agent that I have, so
>>>he is not the problem.
>>>
>>>foreign agent configuration:
>>>
>>># bring up tunnel device
>>>ip tunnel add mode ipip # (default tunnel tunl0; local *->remote *)
>>>
>>># add static arp table entry since mobile node can't reply
>>>ip neigh add 172.24.8.24 lladdr 00:00:0d:2f:a0:b0 dev eth0 nud perm
>>>
>>># add static host route
>>>ip route add 172.24.8.24 dev eth0
>>
>>
>>
>>
>>Is 172.24.8.24 really connected to e

Re: [leaf-user] IPforwarding

[Matthew Schalit]

There's a Dachstein Port Forwarding FAQ lying
around somewhere.  Try to find it, and it will
step you through the hoops.

Once you get the routing correct, you'll also want to have
tinydns (PRIVATE) serving up names for your internal
network so that you can direct your traffic appropriately.
If you don't, then requests from your internal network
for www.yourwebname.com will resolve to your external
IP address and mess things up.

Regards,
matthew



ArisB wrote:
> I have a small problem.
> 
> I use dachstein diskette version (Linux Firewall 2.2.19-3-LEAF) and i have
> installed sshd (from the dachtein CD) on it.
> I got that working.
> 
> Now i have a www server en an ftp server on my internal network.
> I want to reach them from the internet (any IP), so i have to open 2 ports
> in the firewall and foward them to the internal server.
> My external IP adres is 212.127.128.77 i want to open port 3122 for the
> webserver and 3123 for the ftpserver.
> My internal IP adres is 192.168.1.1 and the web server is working at port 80
> and the ftp server is working at port 3123 (internal)
> 
> I just don't understand how it's done, i've read multiple docs and howto's
> (allso the network.conf reference on
> http://lrp.steinkuehler.net/files/packages/network.txt).
> I've allso looked into the mailinglistarchive and could not find exactly
> what i am looking for.
> 
> Can anyone help me out?
> 
> Thanking you in advance,
> Aris




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] Dachstein NIC Card Conflicts

[Matthew Schalit]

Kyle A. Holder wrote:
> Thanks for replying.
> 
> I've since gone back and taken 8390 out.  At first, when things weren't
> working right, I tried putting it in there, thinking there was some sort of
> wierd dependancy or something.  I've searched through Intel's site, and
> found out that I need to be using e100.o.


Theoretically, that driver will work fine.  Read up on it here
ftp://aiedownload.intel.com/df-support/2896/ENG/e100.txt
and see if your adapter is listed.  Be sure to check the board-id
against what's stamped on your board!  That driver is version 2.1.15:

http://downloadfinder2.intel.com/scripts-df/Detail_Desc.asp?ProductID=62&DwnldID=2896

If someone built _that_  e100.c source from Intel against Dachstein,
then you should be able to use that one.  Did they Charles?


But in general, people build the eepro100.o scyld linux networking driver,
which works great for my pro100+ pci adapters.  But you have pro100+ Management.
And that's differnt.  The scyld driver is here:
http://www.scyld.com/network/eepro100.html
Because your pro100+ Management uses the usual 82558 controller,
I'm guessing it will run fine with the eepro100.o also.


Now as far as IRQ's go, network cards have historically taken
IRQ 10.  Because the PCI cards get interrupts before the ISA
cards do, then let the Pro100+ have IRQ 10.  Load it's module second,
as suggested so that it becomes eth1.  Let it autonegotiate
speed and duplex.

3c509.o
eepro100.o


For the 3c509B, the 3c509.o is the right driver, and it's
described here:
  http://www.scyld.com/network/3c509.html
As Brian mentioned, use the 3c5x9cfg.exe dos utility
and force the card to these settings:

IRQ 11,
0x310 (the pro100+ will take 0x300),
PNP=no,
Speed=auto line speed,
Duplex=auto-negotiate,
Tranceiver Type=RJ-45 connector.

It's often a good idea to force the RJ-45, but then again,
you said you had a TPO, and O means "only" :)  You can pick
other addresses, but 0x310 or 0x320 are resonable settings.
Dont' choose 0x2F8, 0x370, 0x3C8, or 0x3F8.  Once you set
those and the utility burns them into the EEPROM, you won't
need any command line switches next to 3c509.o, simply

 3c509.o
 eepro100.o

or
 3c509.o
 e100.o

should suffice :)

Once you force the 3com to irq 11, then go into the
mainboard bios and tell it irq11 is reserved for legacy
ISA cards if possible.

Should work if you don't have it figured already.




>  So, I have since switched to that
> driver, and now, am having IRQ problems, as you have correctly pointed out.
> I am currently trying to figure out if it is possible for me to either
> disable the PNP on my motherboard, or if I have to get some kind of BIOS
> flash.


Flash the mainboard if there's a newer BIOS for it after you back
up the current BIOS.



> I looked at the logs, and found that both cards were attempting to
> use IRQ 10.  Bad news.  Do you know if there is any command-line way to
> change the IRQ of the NICs, or does that *have* to be done through the BIOS?
> BTW, I'm using a P5I430VX-250 Explorer MB.  Sometimes there are jumpers that
> can disable the PNP, but I'm not sure they're on this board.


The PNP subsystem on VX mainboards was new and a little iffy.
Good Luck!
Matthew






---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] trouble with ipip encapsulation tunnels (well,unexpected behavior, really)

[Matthew Schalit]

Chad Carr wrote:
> Hello routing and tunneling guys and gals!  I have a tunneling quandry for
> ye.
> 
> I am doing an implementation of mobile ip and have finally solidified all
> of the protocol bits to implement a foreign agent, and have come to the
> part where I need to accept ip-in-ip tunneled packets for a mobile node,
> detunnel them, and deliver them to him.  I am using the kernel ipip.o
> module for this, and have configured the tunnel as follows:
> 
> __ _  ___
>|  |   | ||   |
>|home agent|===(router)===>|foreign agent|--->|mobile node|
>|__|   |_||___|
> 
> 
> home agent ip- 172.24.8.99
> foreign agent ip - 172.24.20.104
> mobile node ip   - 172.24.8.24 (on the foreign network)



I question the ip addresses below




> 
> I am not in control of the home agent, but I have verified with a sniffer
> that he is sending me well-formed ip-in-ip packets for the mobile node,
> plus he works with anothe foreign agent that I have, so he is not the
> problem.
> 
> foreign agent configuration:
> 
> # bring up tunnel device
> ip tunnel add mode ipip # (default tunnel tunl0; local *->remote *)
> 
> # add static arp table entry since mobile node can't reply
> ip neigh add 172.24.8.24 lladdr 00:00:0d:2f:a0:b0 dev eth0 nud perm
> 
> # add static host route
> ip route add 172.24.8.24 dev eth0




Is 172.24.8.24 really connected to eth0 or is the it eth1?






> 
> I have verified the following:
> 
> 1) The packets are getting delivered to the foreign agent;
> 2) The packets are being accepted by tunl0 and processed;
> 3) They are the expected size (the size of the inner ip packet);
> 4) They are not being delivered anywhere outside the box.



But it seems like you haven't enabled logging all packets on
the foreign agent that come from the home agent or are destined
for the home agent.  I find adding those types of firewall rules
essential to these routing jobs.  Seriously.  Log them packys.

Then you'd see if the traffic is even moving out eth0 on the
foreign agent on its way to the remote node.






> I figure the following bits are true:
> 
> The foreign agent is holding a copy of the ip packet addressed to the
> mobile node.  He may do one of the following:  a) assume that the packet
> is for delivery on the local link, look up the ip in the arp table,
> and deliver it to the mobile node  b) hit the routing table again and see
> the host route, see that it is directly connected, look up the ip in
> the arp table, and deliver it to the mobile node.
>   c) drop the packet
> 
> Obviously, given the way I have configured the box, I believe that "b"
> should be what is happening.  However, it seems plain that "c" is the
> option that has been chosen by the tunl0 device.
> 
> I am obviously missing something quite overt, so I thought that one of you
> guys might be able to see what I can't.



   If you're running a /16 netmask all over, and you didn't tell
us that, then the packets should be accepted unless they are
dropped by the firewall rules or the config is wrong.  At first
glance I don't spot anything wrong, but don't trust that :)

   If the netmask is not /16 all around, then what have you done
on the foreign agent to tell it that it's bridging the two networks,
namely  > foreign agent ip - 172.24.20.104
 > mobile node ip   - 172.24.8.24


   It'd help if you pasted in any relevant messages in from the foreign
agent syslog showing the trail of the packets being accepted and moving
in and out eth cards.   Any masqing/forwarding enabled on the Foreign Host?

Well, got to walk the pooch.  Hope I brought something up
that might be useful,  Matt








---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

[leaf-user] VPN via ssh+pppd or ipsec?

[Matthew Schalit]

I'm finally getting out of the dark
ages and need to deploy a vpn because
one of my users has a laptop on my internal
NAT'd network but will be remote at times,
dialing into an ISP, and I'd like to have them
appear to be still on my network using the vpn howto
method (ssh + pppd) or ipsec I guess.

The laptop is WinXP home, the LEAF box
is Bering rc3, 2nics, static external ip,
plus shorewall.

So which road is good stuff?  ssh+pppd
or ipsec?

Either way, I guess I'll find enough previous
posts, but I can't ascertain the best progs
and current packages I need.

thanks,
matt



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] OOT: DnsCache

[Matthew Schalit]

H. D. Lee wrote:
> Hi Matthew,
> 
> On 2002.09.25_09:39:35_+, Matthew Schalit wrote:
> 
>>I've seen a lot of that  www.blahblahblah.org/ads/* too.  In fact, I
>>get more ads from creative urls than from doubleclick.
>>
> 
> 
> That's why I mention the other options of ad filtering on the previous
> reply.


And they are good options for sure.  I think it's a
losing battle overall, but some things you mention
below certainly help.



>>The problem with filtering ads is that some big money companies that
>>have a lot invested in their site, like financial ones, tie the
>>loading of their pages into the successful loading of the ads and the
>>responses the adserver gives.  So when blocking doubleclick, sometimes
>>your page will wait minutes to timeout and finish loading, if it even
>>does.
> 
> 
> Can you explain the methods they used to enforce this?  


I've not bothered to figure it out, but I suspect
javascript as you do.



> I haven't seen
> anything about this so far. When using the dnscache method, the address
> of doubleclick is directed to localhost, which hopefully will reject the
> packets instead of dropping them. This will result in immediate
> "Connection refused" reply.  


What mechanism rejects the packets sent to localhost?
Don't the packets just hit port 80 which has nothing listening?
When I think reject packets, I think reject them at eth1.



> For redirector, usually an administrator
> will redirect the URLs to local server, fetching a tiny 1x1 pixel blank
> image. It also takes a very short time.


That's a neat idea that I've not heard of.
I don't understand how it works, but that's ok.
I've little interest in web servers at this point.




> My guess is they are using JavaScript or anything of a kind to check
> that. Can you confirm that and explain a bit?

Well, I only know Java2, so I'm not the one to
comment on Javascript, but that's usually the
coding mechanism used on the web.




>>The users will function best if they can have some control of when/who
>>to block ads from.  If they can't adjust the rules that apply to them,
>>a diverse user base will revolt against the best ad blocking software,
>>perhaps.  Donuts in the morning and pizza later on has been known to
>>quash the rebellion.
> 
> 
> Agree. In a diverse user base environment, choosing this is sometimes
> not an option. If the environment is at a big company, the policy have
> to decide about this. If the policy decided to be flexible, there would
> be some methods of authentication to know that an authenticated user
> preferences. This has to be done because the preferences will always be
> on the server side. Presuming a client browser will never have an option
> to disable banner. I may be wrong on this presumption.


In Mozilla, you can right click on an image and ban
images from that server.  You can institute other
simple rules, but I haven't messed with them.





> Now, if this flexibility would be implemented on an ISP, where you can't
> have strict policy, it is much more difficult to enforce this. It is
> absolutely not an option to have a user authenticated before he/she can
> browse. Not the mention the trouble and delay introduced when
> implementing one on a cache proxy.
>  
> 
>>What I've found makes my surfing experience reasonably calm is
>>disabling javascript from opening windows I don't request, using
>>Mozilla's preferences, Advanced --> Windows and Scripting.
> 
> 
> Opera's preferences on JavaScript popup: 1. Accept popup.  2. Reject
> popup.  3. Open popup window in the background.
> 
> Easily switching between 2 and 3 would be very nice. Not that I wanted
> some ad, but sometimes a popup is really not an ad.


Yes that's a problem on big $$ sites also.  I've had
them kindly mention that I need to reenable their
ability to popup a new window, which is not an ad.
Lazy coding on their part?  who knows :)




>>Or an .edu.
>>
> 
> 
> Yes, I wonder how I can miss this one. *g*
>  
> 
>>And on the subject of dnscache and loading it up, people often wonder
>>about extending the TTL, time to live, of the cached data so that the
>>entry is available for longer.  How bout a week?  Well it turns out to
>>be a bad idea apparently, because the whole DNS scheme is centered
>>around timeouts on the order of a 1/2 hour, at least the responses you
>>get from various servers are.  It's rare to see it over 3hrs.  Now you
>>can set a TTL on your cache, but there's TTLs on each entry that came
>>with the entry, and the TTL that came with the entry takes precedent
>

Re: [leaf-user] DnsCache

[Matthew Schalit]

H. D. Lee wrote:
> On 2002.09.24_21:26:59_+, Sean wrote:
> 
>>I'm using Dachstein.  TinyDNS is on the CD.  Guess I'll try to set it
>>up.  Thanks for the pointers!  Another question:  Is this a GOOD IDEA?
>>It can be done, but should it be done?
>>
> 
> 
> Depends on what you and your users needs. On some sites I worked on,
> they really want ad free pages (and some cencorship). Pages come up very
> fast, etc. etc. For that, they used specific apps cooperating with
> squid proxy (redirector), like squirm or squidguard. Junkbuster is
> another good alternative that comes to my mind that have that exact
> function. 
> 
> The benefit of using such apps is flexibility, ...


I've seen a lot of that  www.blahblahblah.org/ads/* too.
In fact, I get more ads from creative urls than from doubleclick.

The problem with filtering ads is that some big money companies
that have a lot invested in their site, like financial ones,
tie the loading of their pages into the successful loading of the
ads and the responses the adserver gives.  So when blocking doubleclick,
sometimes your page will wait minutes to timeout and finish
loading, if it even does.

The users will function best if they can have some control
of when/who to block ads from.  If they can't adjust the
rules that apply to them, a diverse user base will revolt
against the best ad blocking software, perhaps.  Donuts
in the morning and pizza later on has been known to
quash the rebellion.

What I've found makes my surfing experience reasonably
calm is disabling javascript from opening windows I don't
request, using Mozilla's preferences, Advanced --> Windows
and Scripting.


> On the other hand, some sites just don't want restricted accesses, even
> to speed their web experience, or their user bases are just too complex.
> Like ISP.


Or an .edu.

And on the subject of dnscache and loading it up, people often
wonder about extending the TTL, time to live, of the cached data
so that the entry is available for longer.  How bout a week?  Well
it turns out to be a bad idea apparently, because the whole DNS
scheme is centered around timeouts on the order of a 1/2 hour,
at least the responses you get from various servers are.  It's
rare to see it over 3hrs.  Now you can set a TTL on your cache,
but there's TTLs on each entry that came with the entry, and
the TTL that came with the entry takes precedent over the global
value you can set on your cache.
   Your 1 week TTL you placed on the cache will never get a chance
to get used, becuase the 1/2 hr - 3 hr TTL entry on each data will
expire them long before a week ever rolls around.
   It's better this way so that when a server at some ip address goes
down, it's dns entry can be changed to point to a new ip address,
and basically nobody will cache the old address for more than 3 hrs.
But you guys knew that already, I'm sure.


And finally, you can increase the size of your dnscache to greater
than the 2 MB that's set aside for it in your conf files.  I still
haven't found a way to determine my cache size on the fly.  So I
never know if it's near 2MB.  If I was handling a busy site, it
might be something to think about.  Those djbutils become more
useful then.


Regards,
Matthew



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] FTP and IP-NAT

[Matthew Schalit]

Well I guess I got it mostly wrong, as you said
they're running their ftpd on 864, which as you
found, makes it nearly certain that everyone with
a firewall will fail to be able to reach them.

What it has to do with NAT is this, and I'll try
to keep it simple:
   -  The ip_nat_ftp module on Bering or
  the ip_masq_ftp module on Dachstein/Oxygen
  watches for traffic destined for port 21 and
  further searches those packets for the ftp client
  command "PORT aaa.bbb.ccc.ddd.eee.fff"

   -  You're asking it to watch for traffic destined to
  21 and 864, now.

   -  When it finds the PORT command in that traffic, it'll
  translates the private address in the PORT command
  (the aaa.bbb.ccc.ddd part) into your public eth0 ip address.
  In my case, my PORT commands look like this before and after:

PORT 10.1.1.1.234.12

PORT 63.193.214.179.234.12

  Something like that :)

   -  Then dude's ftpd will see your valid public IP and
  a valid port and will try to send the file there,
  rather than try to send it to the private 192.168.1.x
  type of address, which is impossible, a 501.

best,
matthew





Joris Kempen wrote:
> Hi people,
> 
> I got it working.
> 
> Just opened port 864 by using
> 
> IP_MASK_FTP port=21,864
> 
> his FTP is just running at this port. still don't know what it has to do
> with IP-NAT
> 
> but thanks for all suggestions
> 
> Met vriendelijke groet,
> 
> Joris Kempen
> St. Ursulahof 47
> 5995 CB Kessel
> 
> email: [EMAIL PROTECTED]
> tel. nr.:  06 1257 4228




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] Shorewall-1.3.8 DNAT

[Matthew Schalit]

Jason Taylor wrote:
> I'm trying to redirect port 24 to 25 for a single IP.  My rules file 
> line is:
> 
> DNAT loc dmz:10.10.1.1:25 tcp 24 - 10.10.1.1
> 
> It appears that this rule is useless because the original destination IP 
> matches the destination IP.


I'd like to understand why it's useless, but maybe it's just
how the shorewall code processes things.  I've been racking
my brain a bit on this one.  It's an interesting desire,
especially because I wrote one of the original firewalls
used on lrps, before the days of LEAF, and never tried this.




> Leaving off the - 10.10.1.1 portion does redirect all tcp traffic from 
> loc destined for port 24 as expected.


You mean like this?

   DNAT loc dmz:10.10.1.1:25 tcp 24 - -




> However, I would still like to have it dropped unless destined 
 > for this particular host.


That seems easy enough.  Just put another line right above
the one that you've got that works like this:

 REJECT  loc  dmz:!10.10.1.1   tcp 24-   -
 DNATloc  dmz:10.10.1.1:25 tcp 24-   -


Let me know if this works.  I'm digging around for another
nic to setup a dmz to test this, but I may get sidetracked
by the new puppy.

regards,
matthew

















---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] FTP and IP-NAT

[Matthew Schalit]

First of all, can you login to the ftpd?
I figure you can.

But when you try to do a directory listing,
you get that error.

And the error you get from the ftpd server
is   ">>error message: "501 you are on a LAN
and the IP-NAT is not translating your IP address
correctly"


So let's refer to RFC 959, FTP:
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc0959.html
on or about page 37-40 we learn how to decode the three
decimal digits in the response code, which is formed like
xyz, where your response was a 501:


  5yz   Permanent Negative Completion reply

The command was not accepted and the requested action did
not take place.  The User-process is discouraged from
repeating the exact request (in the same sequence).  Even
some "permanent" error conditions can be corrected, so
the human user may want to direct his User-process to
reinitiate the command sequence by direct action at some
point in the future (e.g., after the spelling has been
changed, or the user has altered his directory status.)




  x0z   Syntax - These replies refer to syntax errors,
   syntactically correct commands that don't fit any
   functional category, unimplemented or superfluous
   commands.




  xy1   This is a finer grain subcatagory of the xy value, so
a 1 in the last digit can mean many things.


In the case of 501, the usual meaning is:

   501: Syntax error in parameters or arguments.



So what the server is trying to tell you is that you
sent an invalid PORT command, which was invalid not
because of how it was formed but becuase of the values
of it's arguments.  Something that would cause a PORT
command from a client to a server to be invalid would
be if the client sent and invalid address, that is, an
address from the private non-routeable space like
192.168.1.1.

What is supposed to happen is that those invalid
addresses are supposed to be munged on the fly by
ip_masq_ftp.

Do you have ip_masq_ftp installed?

   # lsmod

should list the mods.

   As far as what your admin said, ignore it.  If one of
my sysops told me he was going to mess with port 864
and try to run a server on that port, I'd ask if he
was sure he didn't want to go into art.

   If you want to be responsible for your own end,
you might check your syslog and paste in any relevant
denied packets if any between you and the ftpd, also.

Best,
Matthew








Joris Kempen wrote:
> Hi people,
> 
> I talked with the admin of the ftp site.
> 
> and he told me that port 864 is needed for IP NAT.
> 
> Can I just open port 864?
> 
> I have DachStein & Echowall, how do I open this port 864.
> 
> Any links maybe that tell me (in easy language:) what IP-NAT exactly is..
> 
> Thanks..
> 
> Met vriendelijke groet,
> 
> Joris Kempen
> St. Ursulahof 47
> 5995 CB Kessel 
> 
> email: [EMAIL PROTECTED]
> tel. nr.:  06 1257 4228 
> 
> 
>>-Original Message-
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED]]On Behalf Of Joris Kempen
>>Sent: Saturday, September 21, 2002 10:14 AM
>>To: Leaf (E-mail)
>>Subject: [leaf-user] FTP and IP-NAT
>>
>>
>>HI people,
>>
>>I have a Dachstein router with EchoWall and SSH on it.
>>
>>I try connecting to a FTP server and get this message:
>>
>>error message: "501 you are on a LAN and the IP-NAT is not 
>>translating your
>>IP address correctly"
>>
>>I didn't have this problem before with this server, so i 
>>assume they changed
>>something.
>>
>>What do I need to change in my router to prevent this problem?
>>
>>Thanks for any help.
>>
>>Joris
>>
>>Met vriendelijke groet,
>>
>>Joris Kempen
>>St. Ursulahof 47
>>5995 CB Kessel
>>
>>email: [EMAIL PROTECTED]
>>tel. nr.:  06 1257 4228




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] SSH & Bering Leaf

[Matthew Schalit]

Jeff Newmiller wrote:
> On Sun, 22 Sep 2002, Matthew Schalit wrote:
>>Hosts.allow only comes into play if sshd is being started via /etc/inted.conf:


> Matt... sshd also checks /etc/hosts.allow itself if compiled to do so.  
> Most binaries for LEAF boxen are compiled this way.


Yea, I've messed with that when compiling it myself,
and I was was wrong to make such a blanket statement.

But it's not enabled on the pre-rolled sshd-3.4p1 by JN.
So that specific version won't use hosts.allow when
running standalone.  That's what I was thinking after
having tested it.

thanks,
matt



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] SSH & Bering Leaf

[Matthew Schalit]

Jacques Nilo wrote:
> Le Dimanche 22 Septembre 2002 21:31, sr a écrit :

>>or is there more to do?

> Yes
> Check hosts.allow :-)
> 
> Jacques



Hosts.allow only comes into play if sshd is being started via /etc/inted.conf:
===
#:OTHER: Other services
sshstream  tcp nowait  root/usr/sbin/tcpd  /usr/sbin/sshd -i
===

Following your docs, this would be commented out, and
the daemon would be running standalone from init.  A better
line in your /etc/shorewall/rules would be something like:

ACCEPT  net:128.287.333.12 fw   tcp   22

or

ACCEPT  net:128.287.333.0/24   fw   tcp   22

if'n you know where'n ya'll are gonna be comin' from,
because it's more restrictive.

regards,
matthew




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] bering with PKGPATH=tftp://tftpserver/tftpboot wouldbenice

[Matthew Schalit]

Erich Titl wrote:
> Hi Lynn

> you can always load packages later. You need a minimum of packages on 
 > the CD/floppy which allow network access, then you could load the other
 > goodies from the net.


   Someone posted a mini-HOWTO use the boot eeprom on a nic to boot
from the network without any floppy or cdrom.   That was some
months ago, but it was this year.

   I knew it was possible, but I didn't think I had the eeproms
on any of my nics.  Well it turns out that the Intel Pro100+
comes with the eeprom built in.

   So I messed around with it (you update its 64K of code with
some config info using the Intel utility program) and it will
contact your tftp server and load your cd image no problemo.

   If you can deal with the security risk, and if you've got
the built in boot prom, then booting off the nic seems to be
the minimum of the first derivative.

have fun with your 'puters, naw.
matthew







---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [leaf-user] bering with PKGPATH=tftp://tftpserver/tftpboot wouldbe nice

[Matthew Schalit]

   The only downside I've found to booting using remote packages
for the LEAF box is that my LEAF box is my router and tinydns
nameserver.  So when it's still trying to boot, the internal
network can't resolve itself and whatnot.  When that happens,
the remote computer that would be serving up the packages to
the LEAF box is unhappy because it's default route is down and
it can't resolve names.  The lack of nameservice and default
route makes the loading of packages painfully slow.  But if the
route's up, the packages load like a bat out of h e double hockey
sticks.

   So the only way I like my LEAF is for it to be self
sufficient.

Matthew
(now back to salmon restoration :)





guitarlynn wrote:
> On Tuesday 27 August 2002 05:46, Karl Gaissmaier wrote:
> 
>>Hi Bering developers && users,
>>
>>has someone already thought about to broaden the PKGPATH concept?
>>
>>It would be very helpful to have a bering CD/FD and download
>>some additional packages via tftp|http|scp|...
> 
> 
> Oxygen and OpenBrick (Bering/Wisp/dist) support tftp'ing of a boot
> image from a remote server.
> 
> 
>>Most useful, the backup (partial backup) should use this
>>feature too, to save your changes on a centrally administered
>>server. You could then use one Bering CD for your different
>>Firewalls on the campus with one centrally administered
>>config files.
> 
> 
> Neat idea!
> 
> 
>>Someone already working on this?
> 
> 
> I am not aware of anyone working on this at the moment, but
> it is possible that someone is that I am not aware of.




---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Re: [Leaf-user] dachstein cd 1.0.2: keyboard and cdrom errors

[Matthew Schalit]

 
> unfortunately, i'm configuring the firewall right now (as in setting up
> the networking parameters) so ssh doesn't work quite yet.  a keyboard
> would be useful.   :-)

Dachstein 1.0.2 is called Dachstein Firewall for
the good reason that it comes complete.  It is
well enough written, including QoS, that you
can get by to start with using it, as long as
you use 192.168.1.0 for your internal network.
Want a DMZ too?  Not a problem.  Want a different
firewall?  There's Shorewall, Echowall, rcf, and pfw.
The first uses iptables, the last three use ipchains.

 
> a friend gave me an old pentium II/233.  perhaps my old pentium I/66
> outlived its usefulness.  i rebooted dachstein on the new machine with
> no problems (and boy was it faster).

You're P66 was fast.  The P2 is different mobo, 
chipset, and bios.

> it kind of sucks that i had trouble with older hardware; seems like the
> very thing that LEAF should thrive on.  

LEAFs work well on older hardware, but maybe not 
the really old stuff, because it doesn't support 
pci cards, and those run well at 100 Mbps...

> on the upside, boot time is now cut by a third.  

People rarely reboot the firewall.  So boot speed
is not that significant, though using a cdrom
to load all your packages is what's fast.

> and my firewall would be able to accept/reject packets
> VERY QUICKLY.  :)

Yes, but how much quicker than the P66?  I have a
good feeling that any fine resolution timer will
show that your packets are not delayed during routing
by the LEAF more than 10 ms using any funky old hardware 
you can run.

> with only 2 days till school starts again, i want this firewall up
> asap...
> 
> pete

Good luck.  I was sort of wondering what's
going on, because the latest DF is so slick that
it comes right up in about 30 mins, if you've set 
one of these up before and know your network.conf,
and your modules.conf.

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] dachstein cd 1.0.2: keyboard and cdrom errors

[Matthew Schalit]

"David B. Cook" wrote:
> 
> Even if the keyboard is not your specific problem, eliminate it. Your
> firewall is a server that is available by SSH so there is no need for
> keyboards cluttering up you area. 


I need a local keyboard.  Working without a 
keyboard via ssh only is not always an option.  
The firewall that I write has a scram switch that 
completely isolates the firewall.  People would 
want to do that if they think their LEAF security
has been compromised, effectively ending any
remote connections.  Going to the keyboard
then is how they get in.  I have a workaround
in development where I only allow in ssh on a 
random port after a scram.

If a person wants to use a null modem cable
to connect the serial port on their LEAF to
the serial port on another computer on their
LAN, I can see this  eliminating the need for
a keyboard as you describe.

Thanks for the tip.
Matt

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] serial console

[Matthew Schalit]

guitarlynn wrote:

> Any advice or suggestions would be appreciated,


Kermit (now capable of using ssh),
and, in general, man getty.

Matt

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Is this newbie even in the right ballpark with LEAF?

[Matthew Schalit]

Dan Schwartz wrote:
> 
> Good evening, folks!
> 
> Over the past few days I've received some very helpful guidance about
> assembling LEAF VPN appliances to handle multi-megabit 3DES encryption
> throughput rates; and I really appreciate the guidance given this Mac & NT
> geek (& linux newbie).

What's the consensus?  You can have a 300 MHz PII running at 450 MHz,
and a pci bus running at 33 MHz, on a 100 MHz FSB using PC100 SDRAM.
Um, that's fast.  It'll cost you about $100 to put it together and test,
assuming you have most of the part in your closet.  I have a suspicion
that more than a few of you out there have broken the GHz barrier :-o


> However, since LEAF is essentially a small, stripped down (yet robust!)
> router that fits on 1 or 2 floppies, is there another router/encryption
> project out there in *nix land that's more suited for high capacity, i.e.
> something on the order of an Intel NetStructure 31xx VPN gateway
> ?


You're talking about 

  Low end Intel  High End Intel
 -
  233 MHz Cpu733 MHz Cpu
  3 Mbps 3DES throughput 95 Mbps 3DES throughput

That's a big difference.   I'm sure you could put together
a LEAF box with a PIII 800 and 512 MB ram, but you're asking
for other companies solutions, and I'll let someone else
answer that.  I'd like to think a LEAF box could keep
up until it's compared to some fancy hardware with a modified 
PCI bus or multiple PCI buses.

Good Luck,
Matthew 





> Thanking you in advance,
> Dan Schwartz

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] sysrq key in Oxygen?

[Matthew Schalit]

"Ryan P. Matijcio" wrote:
> 
> In /etc/sysctl.conf:
> 
> # Do enable the magic-sysrq key
> # -- only present in some Oxygen 2.2.17 kernels
> kernel.sysrq = 1
> 
> What does this do?  Also, if you change these values how do you get
> Oxygen to recognize the change?


You can safely disable it, ie kernel.sysrq = 0,
on your Oxygen box, because they use a newer kernel.
That deprecated variable only worked at one
point in the development cycle, was once removed
at my request, and has crept back in.

Matthew

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] ssh / openssh?

[Matthew Schalit]

Julian Church wrote:
> 
> Hi All,
> 
> I use ssh to access and administer my Dachstein firewalls. (one home, one
> office).
> 
> I'm a bit confused because there seem to be two versions of sshd.lrp
> available at the moment -
> 
> The one I've always used is quite small, is called sshd.lrp, is available
> at ftp://ftp.linuxrouter.org/linux-router/dists/2.9.8/packages/ and is
> referenced in Steve Peck's sshd howto
> http://c0wz.steinkuehler.net/dox/sshd.txt.
> 
> The other one is much bigger (too big for my floppy), is also called
> sshd.lrp, requires that I use libz.lrp and is part of openssh maintained by
> Jaques Nilo at http://leaf.sourceforge.net/devel/jnilo/index.html.
> 
> Could someone explain the differences?  Are the differences worth worrying
> about?  Should I consider upgrading?
> 
> cheers
> 
> Julian


You definitely want to use J. Nilo's most recent ssh package,
which I'm pretty sure is an OpenSSH implementation.  You just 
need a second floppy or to use CDROM for your packages.  Try
Dachstein CD if you want.

Matthew

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] upgrading lrp box

[Matthew Schalit]

Robert Chambers wrote:
> 
> Good idea.  I'll try it with the Netgear FA311 and one 3c509b card.
> 


Post your results and with any specifics
that might be interesting, if you have time.
Thanks,
Matt

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Resolution: Why cant I ping on Dachstein rc2?

[Matthew Schalit]

"Dr. Richard W. Tibbs" wrote:
> 
> Folks, I want to thank everyone again for the *exhaustive* support
> trying to debug my ping problem.
> Here is what finally worked :
> 
> I downloaded and compiled the latest natsemi.c (actually did this on the
> Suse box),
> put the new natsemi.o on a floppy and mounted it on the dachstein box.
> Once I replaced the older natsemi.o under /lib/modules,
> backed up my ramdisk (options 5 modules),
> rebooted and all is well.
> Whew, what a marathon :-)
> 
> Again thanks for the superlative response to my problems


Well, you obviously deserved it.  You went and did
something awful crafty, building your own driver.
Now I guess the rest of us could benefit if you made
that available to Charles or the sourceforge site.  
I guess the newer fa311's need it, and they are popular.

I got left out of the thread Why didn't the fa311.o
file work for you?  Isn't that for that card?  I found
a reference to natsemi.o myself, but I didn't think it
would take precedence over a driver named after the card.

Regards,
Matthew

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] AT&T transition woes

[Matthew Schalit]

David Douthitt wrote:
[snip]

> It would be nice to know what happened.  However, I've been using the
> current pre-release version of Oxygen with DHCP routinely - especially
> since I don't have to configure it :)
> 
> It works just fine.

We tried Oxygen-120801.  It just froze during boot right after
loading the dhcp program and attempting to get an ip address, 
which it said it got.  

He doesn't want to take down his router to test out 
12/11, though, because he has work to do.  Sorry.
Matthew

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] AT&T transition woes

[Matthew Schalit]

Gary and Cindy Cote wrote:
> 
> --- Matt Schalit <[EMAIL PROTECTED]> wrote:
> > gc wrote:
> > >
> >
> >
> > Describe exactly what you did and what you saw, if
> > it's
> > still happeing and the DNS advice you got doesn't
> > fix it.
> 
> o Downloaded Dachstein 1.0.2 distribution
> o Loaded it onto a floppy
> o Selected appropriate modules for my NIC cards
>   in /etc/modules (8390 and ne2k)


Do either of these need pci-scan?  I'm not looking
at the deps file right now, so I'm just curios.



> o Commented out the masq_quake module
> o Tried to enable a serial port console in
> /etc/inittab
>   (which didn't work, btw, but i'll figure that out
>some other day)
> o Backed up /etc
> o Added a "send host-name" line to dhclient.conf

I didn't have to do that.  Why don't you leave it
commented out for now.  It may be sending an invalid
string.


> o Backed up dhclient
> 
> o Rebooted
> o Observed the DHCP sequence go through successfully
> o Examined IP address and routing table. Nothing
>   apparently out of the ordinary.
> o The 'ip route' command showed an entry that said
>   something like this:
> 
> 11.22.33.44/28 <...> src 22.33.44.55
> 
>   o I could not ping 11.22.33.44 (what I believe
> should be my next hop router, yes?)
>   o I could ping 22.33.44.55
>   o I could not ping any other nodes
> 
> (Sorry I don't have exact IP addresses. I'm at work
>  at the moment. I can supply them tonight if it would
>  be helpful)

Yes those will be necessary.  We'll need to see
the relevant portion of 

 dmesg

and the entire output of

 ip addr show
 ip route show

 
 
> > > If I hook my win2k box directly to the cable
> > modem, everything works fine.
> >
> > Yea yea.  And if I suck Bill's cock, he might let me
> > drink
> > from the river of wealth.
>
>
> Now, now...that wasn't a jab...i was simply making the
> point that the problem appears to be on my end.

I can not believe I posted that.  For the love of 
Pete!  You didn't do anything wrong at all.


 
> > Just so you know, it's common to get a new IP
> > address an whatnot
> > when you switch systems (and thus mac addresses) and
> > get a new lease.
> > I didn't have to touch a single dhcp setting to get
> > my friend's
> > attbi.com system in Petaluma, CA to work.
> 
> That gives me an idea. I know someone who had a
> problem when they unplugged their old computer from
> the cable modem and plugged a new one in. Turned out
> the system 'remembered' their MAC address and would
> only give them one IP address (in that case, though,
> DHCP was failing). The technician told them to power
> down the modem for five minutes and that cleared it
> up. I don't fully understand why, but there it is.
> 
> modem for five minutes. I'm not sure why that seemed


You're post cut off there, but the computer nics and
routers communicate by the hardware mac addresses burned
into the card, and the ip addresses are just numbers we
assign.  When you release the lease, you clear out the
mac addy to ip addy mapping.

I was going to recommend that you use your windows box
to release the lease, but then I remembered you had
only Linux, so I erased it.  I don't know how to release
the lease on Linux.

Good Luck,
Matthew

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Why can't I ping from a Dachstein box?

[Matthew Schalit]

Ray Olszewski wrote:
[snip]

> >The ioports file shows no entry for eth1 or eth0 explicitly (should
> >there be?)
> 
> Yes. Do you have your BIOS set to NOT running a PnP OS?
> 
> >There are items called "pic1" and "pic2" and "dma1" and "dma2".
> >All the addresses seem rational.

Did we get to the part where he posts his 

  lsmod

and his

  ip addr show

???  I forgot to ask that in my other post?
I mean, if his network doesn't run ???  Does
he need pci-scan module?

Okey
Matthew.

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Why can't I ping from a Dachstein box?

[Matthew Schalit]

What you want to do at this point is either
modify the firewall ruleset text file to specify 
loggin the traffic so you can see what is happening, 
or you can insert the rules to do so into the
ruleset that's running.

You would want to add the -l switch to the default
rules for input and output.  That's the rule that
the traffic is matching, based on the byte counts
in the ipchains -L -n you posted.

Once you've added the -l switch and reloaded,
make the traffic and look at your syslog.  You
should see quite a bit of the exact answer as
to what is going on.

  When sitting at the LEAF and pinging an internal
  LAN computer, outgoing ping is ICMP type 8.  The
  response are input on eth1 as ICMP type 0.

Those are allowed according to your rules.

If you have trouble making the correct rule
modifications, post, and we'll give you the
exact syntax.

Regards,
Matthew

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] FTP Server - Change default ports

[Matthew Schalit]

Simon Bolduc wrote:
> 
> Hey All,
> 
>   I'm running an FTP server behind my Dachstein 1.01 router, and rather than
> have hundreds of scanners hitting my FTP server on port 21 and try and hack
> an account I'd like to move it to a different and much higher port number
> (above 1024 if possible).  I've checked on google but not found anything
> that works.  Most related articles refer to changing the ip_masq_ftp line to
> read:
> 
> ip_masq_ftp ports=port#,port#
> 
> this doesn't seem to work - and logging into port 21 still works.  I am
> running Seawall 4.1.1 if that makes any difference.  Any and all help is
> appreciated.
> 
> S


I can help you with a different firewall solution.
I wrote a firewall for Oxygen and Dachstein that
handles your simple request.  I think that you may
have had problems with your newish ip_masq_ftp command
if the ip_masq_ftp.o modules is an older version that
doesn't support it.  The command you quoted is new to me,
and I really shouldn't comment.

If you want to try out my firewall, it's called pfw.lrp,
Packet Firewall v.1.0, at  ftp://ftp.schalit.net/pub/

In the /usr/local/etc/popts , the optional services file,
I use the following lines to forward two different
ports on my firewall to port 21 on my ftp server.

 YodaFtpC1=$IPX:21>$YODA:21>$WORLD:all>tcp>log \
 YodaFtpC2=$IPX:710>$YODA:21>$WORLD:all>tcp>log \

That's an example of how I run what looks like an ftp server
on port 710.  If you try out pfw, I can walk you through
it.  You can fire it up without making any changes and
it will work, but it won't accept any inbound services
until you edit the popts file.

Good Luck,
Matthew

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] FTP server problem

[Matthew Schalit]

Stewart Adey wrote:
> 
> ##INTERN_ftp_SERVER = 
> ##Default: STD=INTERN_SSH_SERVER=10.10.104.1
> ## Others Undefined
> ## EXT=All Undefined
> ##Scripts: STD EXT
> 
> ##This group of variables controls port-forwarding services from the LRP box's
> ##external interface to internal machines.  Allowed xxx services are FTP, WWW,
> ##SMTP, POP3, IMAP, and SSH.
> 
> ##Services forwarded using these variables are always forwarded from the LRP
> ##box's external IP address (see EXTERN_IP, above).
> 
> ##If you expect people on the internet to be able to use your server, you must
> ##also open the appropriate ports in your firewall rules (see EXTERN_UDP_PORTS,
> ##EXTERN_UDP_PORTn, EXTERN_TCP_PORTS, AND EXTERN_TCP_PORTn, ##above).
> 
> Is this above segment for FTP Servers with port 21 or is it all ftp servers all 
>ports?


It looks like it's used to tell DF that you have
and internal ftp server at a certain ip address.
I think it assumes the ftp server is listening
on port 21 on the internal server.  Then it mentions
that you also need to use the EXTERN_* variables
further down in the script to open up and portforward
the ports of your choice over to the ftp server.
I think you can choose if you want you firewall to
listen for ftp on port 21 or whatever port.  Someone
else may have to help you with the exact syntax. 
There must be a simple readme for DF or ES2B for
setting up ftp, or at least a post on the mailing list
archives.

regards,
Matthew

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Opening Ports on Dachstein

[Matthew Schalit]

> Stewart Adey wrote:
> 
> Hi, I'm unsure how to open ports to allow an FTP server running behind 
> it on port 6660 (or 21 if for example).  

You have to edit /etc/network.conf.  In there are
directions.  Search this list by using the search
engine at sourceforge and you'll find similar 
questions.

> I have a feeling it's todo with ip_masq_ftp.  

Nope, that module is used for outgoing ftp,
not incoming.  It's used to help outgoing ftp
work behind a masq'ing firewall.  Outgoing active
ftp needs that help.

> As i'm a n00bie to this step-by-step instructions 
> would be usefull.  Thanks in advance... STU.

I defintely haven't had enough coffee yet for step
by step anything :-o
Matt

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Dachstein multicron-p updatetime() bug

[Matthew Schalit]

Charles Steinkuehler wrote:
[snip]

> There's always:
> ps axc | sed /grep/d | grep xntpd
> -or-
> ps axc | sed -n '/sed/d;/xntpd/p'


I like the Oxygen ps command, because I can type

  ps h -C xntpd

and it will print out only the xntpd line if it's
there, and nothing otherwise.  Sort of like 'which'.

Regards,
Matthew

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] What is This

[Matthew Schalit]

Victor McAllisteer wrote:
> 

> This is some crazy method of geographic load balancing.  A whole lot of
> boxes use TCP port 53 simultaneously to find out what part of the world.

Victor, wouldn't the load balancing we've seen over the
last months that hits port 53 by SYN traffic?  Why
are all his log entries refering to non-SYN traffic,
i.e. responses?

Matthew

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] What is This

[Matthew Schalit]

"Sean E. Covel" wrote:
> 
> Is this what they call FireWalking?  This is my welcome to the new ATTBI
> network.  Got more of these than Nimda or Code Red hits.  Goes on for
> pages.  1888 today.  Any thoughts?

It looks annoying at first glance.  Are you using dhcp?  Just wondering.
If so, did you have to enter c1240165-a as your hostname into /etc/hosts
or /etc/hostname or your  /etc/rc.config.d/dhcp conf file?
 
All these are blocked by rule #42.  What is that rule?
These log messages are from strange hosts.  80% of them don't
resolve to a real hostname.  All the packets you listed are
tcp packets with no SYN flag, meaning they are theoretically
responses to some tcp dns request your machine made.  Because
they are all response packets, I'm not sure what's going on.
I don't know why you're getting responses from so many odd
computers.  The other strange thing, is that I would expect
your firewall rules to allow response to outgoing TCP DNS requests.
That's why I want to see rule 42.

   ipchains -L > /tmp/myrules
   vi /tmp/myrules, find line 42, and post it.

Your custom cd boot only sounds nifty.
Post a mini-HOWTO when you get it done.
Matthew


> Dec 8 20:50:12 c1240165-a kernel: Packet log: input DENY eth0 PROTO=6
> 194.205.125.26:32881 12.243.228.133:53 L=44 S=0x00 I=0 F=0x T=242
> (#42)
> Dec 8 20:50:12 c1240165-a kernel: Packet log: input DENY eth0 PROTO=6
> 216.220.39.42:59118 12.243.228.133:53 L=44 S=0x00 I=0 F=0x T=236
> (#42)
> Dec 8 20:50:12 c1240165-a kernel: Packet log: input DENY eth0 PROTO=6
> 64.56.174.186:30087 12.243.228.133:53 L=44 S=0x00 I=0 F=0x T=238
> (#42)
> Dec 8 20:50:12 c1240165-a kernel: Packet log: input DENY eth0 PROTO=6
> 202.139.133.129:53767 12.243.228.133:53 L=44 S=0x00 I=0 F=0x T=235
> (#42)
> Dec 8 20:50:12 c1240165-a kernel: Packet log: input DENY eth0 PROTO=6
> 203.194.166.182:51122 12.243.228.133:53 L=44 S=0x00 I=0 F=0x T=231
> (#42)
> Dec 8 20:50:12 c1240165-a kernel: Packet log: input DENY eth0 PROTO=6
> 62.26.119.34:58275 12.243.228.133:53 L=44 S=0x00 I=0 F=0x T=242
> (#42)
> Dec 8 20:50:12 c1240165-a kernel: Packet log: input DENY eth0 PROTO=6
> 194.213.64.150:21170 12.243.228.133:53 L=44 S=0x00 I=0 F=0x T=237
> (#42)
> Dec 8 20:50:12 c1240165-a kernel: Packet log: input DENY eth0 PROTO=6
> 203.208.128.70:12351 12.243.228.133:53 L=44 S=0x00 I=0 F=0x T=242
> (#42)
> 
> BTW, I just switch from ESB2 to Dachstein CD.  Went S smooth!
> Nice to have MAJOR storage, and FAST boots.  Charles, you are a GOD.
> The partial backup scheme was not too confusing.  Only took 3 tries to
> get the partial and destination settings correct.  I added PortSentry
> (on my floppy backup).  I think once I'm happy with the setup, I'm going
> to do a full backup of everything onto diskette, then dump the CD to a
> hard drive.  Overlay the HD with the diskette backups, and burn a new
> CD.  The point is a completely custom setup that boots CD only!  Nice
> job!

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Re: Weblet and SSHD

[Matthew Schalit]

Etienne Charlier wrote:
> 
> Wouldn't be better to comment the exit 0 in the scripts released by Jacques
> ?

That's what I meant.  Commenting the exit 0 in /etc/init.d/sshd
allows that script to run through to its end, during which time 
it attempts to start sshd stand-alone.

In addition to commenting the exit 0, you would want to comment
the ssh line in /etc/inetd.conf.  That way, you only get a stand-alone
daemon and inetd will not try to start one.

What I describe applies to J. Nilo's recent release of sshd.lrp.

 
> In the current situation, we must edit something to make it work
> ( the script or the inetd.conf)

Both with the current sshd.lrp, if you want standalone.
Standalone is very good.  It will spawn an instance of
the sshd for each new connection.


> if the default script has the exit 0 commented, it will work stand alone. 

Correct if you meant the /etc/init.d/sshd file by "default script."

> If one wants inetd then she must edit 2 files (the script and inetd.conf) ??

It sounds like you have it exactly backward.

   2 files to edit for stand-alone (inted.conf and sshd)
or 1 file to edit for inted-run.   ( only inted.conf   )

if we're talking about the new sshd.lrp from J. Nilo.

> Regards
> Etienne


Btw, what's wanadoo?  I get many more hacking attempts
from that domain than any other.  The famous ftp hack
from [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]

matt

> PS:congratulation to all the persons making the leaf project what it is
> ( a greatly usefull piece of work)

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Routing exsplanation needed

[Matthew Schalit]

Troy Aden wrote:

> > eth2_MASKLEN&
   ^^^
Is this notation valid?
Tony was using the $ symbol on the
other two interfaces, then he used the &.

I've never seen it before.  Is that bash/ash/ksh?
Thanks,
Matthew

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Re: Weblet and SSHD

[Matthew Schalit]

Sandro Minola wrote:
> 
[snip]

> If yes, the only thing you have to do is to comment it out again.
> 
> Hope this helps


If you comment out the ssh line in inetd, be sure to
have a look at /etc/init.d/sshd because it often has
these lines in it, at the top:

  echo "Sshd started vi inetd."
  exit 0

You know this affects you if you see it and not
the sshd 'usage:' when you type:

svi sshd

People need to remove at least the exit 0 to get the
script to run at boot and start sshd stand alone.  Then
issue the svi sshd start command.

Regards,
Matthew

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] dnscache Dachstein 1.0.1 "LRP Box internal IP"

[Matthew Schalit]

Charles Steinkuehler wrote:
> 
> > > Under Package configuration - dnscache there is a menu entry called "LRP
> box
> > > internal IP (default: 192.168.1.254).
> > > But if I open menu entry 1) there is not "192.168.1.254", it's
> "0.0.0.0".
> > >
> > > What's correct now? Is the menu entry description wrong or the value
> itself?
> > > One must be wrong. I entered 192.168.0.254 instead of 0.0.0.0 (my subnet
> is
> > > 192.168.0. not 192.168.1.)
> >
> > Well in my original LRP package IP is setup by default to 192.168.1.254
> which
> > is the default adress of the internal interface of the LRP box. Apparently
> > Charles changed that in the Dachstein setup to 0.0.0.0. There must be some
> > reason but honestly I do not see it at that point.
> > Charles ?
> 
> This is the 'listen' IP for DNSCache.  I changed it to 0.0.0.0, since I have
> configured the firewall to use 127.0.0.1 for a DNS server, which eliminates
> the need to put the internal IP in the prepend statement of
> dhclient.conf...one less thing to change if someone alters the internal
> network numbering.
> 
> Charles Steinkuehler


If it's the listen IP address, why isn't it still
listening on the internal nic, 192.168.1.254?
If someone makes a request on 192.168.1.254, is
dnscache listening on port 53?  Is it listening on
the external IP port 53?  I would think it would
be doing because you used the 0.0.0.0 notation that
I though means all interfaces.

Regards,
Matthew

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] ssh

[Matthew Schalit]

Bill Hults wrote:
> 
> Hi
> Can someone point me to an instruction for setting up ssh on Dachstein.
> I've copied sshd-1.lrp & sshkey-1.lrp to the disk, generated a key,
> saved it but it's still looking for a key.
> TIA
> 

Did you use this?

  ssh-keygen -f /etc/ssh/ssh_host_key
  ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
  ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key

That's what I had to do on Oxygen with OpenSSH-2.9p1.
Perhaps your sshd is looking there or somewhere else.
I think you can enable debug in the sshd_config file
and find out where.

Regards,
Matthew

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Dynamic DNS

[Matthew Schalit]

Stephen Lee wrote:
> 
> Opps! My fault for not reading the message more closely. Yes they are 2
> different products.
> 
> Stephen
> > Is OPENSSH and OPENSSL not 2 different products...???
> >
> > -Original Message-
> > From: Stephen Lee [mailto:[EMAIL PROTECTED]]
> > Sent: Sunday, October 28, 2001 15:59
> > To: [EMAIL PROTECTED]
> > Subject: Re: [Leaf-user] Dynamic DNS
> >
> >
> >> The bigger problem is that I don't *think* openssl has itself been
> >> ported to LEAF. (If I'm mistaken, would someone please correct me.) I
> >> don't have a running ES2B router at hand to check, but openssl and the
> >>  libraries it depends on (libcrypto and libssl) are probably not
> >> available off the shelf for any LEAF version.


I realize that most of you don't consider
Oxygen to be a useful, but in reality, it's
a very complete and modular package.
Both libssl and libcrypto are available at:

   http://leaf.sourceforge.net/pub/oxygen/packages/

-- being libssl.help  ---
OPENSSL

These are the OpenSSL libraries version 0.9.6 compiled for glibc 2.0.
Included are libcrypto.so and libssl.so; libssl.so requires libcrypto.so.

These libraries are useful with various things that use SSL, including
web servers and SSH and other things.
 end libsskl.help 

And finally, since when does openssh work without openssl?
If a recent openssh is available from J. Nilo, it probably
includes libssl and libcryto.

Regards,
Matthew

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Spawning TOO fast error message..

[Matthew Schalit]

> "Reginald R. Richardson" wrote:
> 
> It's constantly showing up in my logbook.
> Can some one explaind me, what this message mean, and how to stop it from showing up 
>in my logs
> 
> Oct 28 10:01:05 dominica-gw02 init: Id "1" respawning too fast: disabled for 5 
>minutes
> Oct 28 10:01:06 dominica-gw02 init: Id "2" respawning too fast: disabled for 5 
>minutes
> Oct 28 10:07:47 dominica-gw02 init: Id "1" respawning too fast: disabled for 5 
>minutes
>  Oct 28 10:07:48 dominica-gw02 init: Id "2" respawning too fast: disabled for 5 
>minutes
> Oct 28 10:14:28 dominica-gw02 init: Id "1" respawning too fast: disabled for 5 
>minutes
>  Oct 28 10:14:30 dominica-gw02 init: Id "2" respawning too fast: disabled for 5 
>minutes
> 
> thnks


That's the output of getty, I think, which is
is a program used to spawn a login shell for
a tty.  In your case, my guess is you're using
an older Oxygen that has extra entries in
/etc/inittab for the two serial ports which
you're not using?

Comment those lines out, backup, and reboot?
Matt

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Hot to display current masqueraded connections??

[Matthew Schalit]

[EMAIL PROTECTED] wrote:
> 
> Hi all,
> 
> I´m trying to display how many users are accesing the internet thru my firewall
> I´ve tryed with netstat
> 
> / # netstat -Mn
> masq_info.c: Internal Error `ip_masquerade unknown type'.
> 
> Does enyone know why do I get this error??
> Is there any other way of doing this??
> 
> I´m using Eigerstein  - Linux 2.2.16 #2 Mon Jul 31 09:38:22 CDT 2000 i386
> unknown
> 
> Thanks


Do you have ipchains -M -L -n ???
Matt


___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Debug Script Available

[Matthew Schalit]

Robert Williams wrote:
> 
> Hi all,
> 
> I have written a shell script to automatically creates data useful in
> diagnosing LRP/LEAF problems.
[snip]
> http://home.pacbell.net/rcw1/lrp/debug/debug.html
> 
> Enjoy, Robert Williams


I like it.  I was working on something similar,
but I went off topic :)

I'd suggest you have the script include

  cat /etc/hosts
  cat /etc/resolv.conf
  cat /etc/nsswitch.conf

and maybe write a couple of lines of code that
ping the network cards with the output perhaps,
and maybe then include arp -an.

Also you might want to code the commands into

  IPCHAINS = /sbin/ipchains
  CAT  = cat
  NETSTAT  = blah blah, and make it test for each command
 to be sure it's there.  Some of the commands
 are not available in Oxygen until you load
 their package (netstat, ipchains, ifconfig)...

Happy,
Matt

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

[Leaf-user] syslinux VGA= syntax?

[Matthew Schalit]

Would someone post the syntax for the syslinux.cfg
command VGA=?  Thanks.  I've tried

  VGA=auto<--- Works, sets default screen size, 80x25.
  VGA=ask <--- Works, asks you for the mode you want.

  VGA=1   <--- Broken:  trying to set mode 1 = 0F01 = 80x50
  VGA=0F01<--- Broken:  trying to set mode 1 = 0F01 = 80x50
  VGA=80x50   <--- Broken:  trying to set mode 1 = 0F01 = 80x50

Thanks,
Matt

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Oracle 8

[Matthew Schalit]

Todd Pearsall wrote:
> 
> You should be on the right path.  port 1521 is the default Oracle listener
> port.  Once you connect to the listener it spawns processes on other ports
> to continue the conversation.
> 
> With Oracle inside the firewall you need to let 1521 in and then Oracle
> starts communication on the other ports that LEAF should let out.
> 
> Does the Oracle box have a routable IP or is it masquareded.  If it's
> masquareded be sure to open 1521 and then forward it to the Oracle box.  I
> would assume the dynamically assigned ports would be handled fine by the
> normal masquarding logic. (maybe?)
> 
> Sorry for the lack of specific suggestions.


That was great.  Just to reword it a bit, on the LEAF:

  The internal nic is generally set by the firewall rules
to accept everything inbound and outbound.

  There's a masq rule for the private internal lan.

  The external nic is then opened to new TCP and/or UDP traffic
on port 1521 both inbond and outbound.

  A portforwarding tunnel rule is then set in place that
forwards TCP and/or UDP traffic from the firewall IP on port
1521 to the Oracle computer's IP on port 1521.  Even though
the rule is "from this comp to that comp," it really is
"back and forth between comp and comp."  It's a 2-way tunnel.
Any traffic from the Oracle IP's port 1521 destined for the 
Internet will get tunneled, and it will then look like traffic 
from your firewall IP's port 1521 destined for the internet.

  And finally, all traffic from the internal lan is allowed
out the external nic, with a few caveats for the paranoid :)

  Because a firewall generally logs everythings that's not
specifically allowed, any strangeness should appear in the
syslog, and you can make adjustments as necessary.

Regards,
Matt

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Cacheing DNS question about 10.x.x.x zones

[Matthew Schalit]

Charles Steinkuehler wrote:
> 
> >   I'm sort of confused, and maybe someones seen this.
> > If I run a cacheing dns server somewhere on my private
> > internal lan (10.x.x.x), then, by definition, it's not
> > authoriative for my zone and just cache's query responses
> > it gets back, correct?
> >
> >   If you guys run a cacheing dns server, how do you
> > configure it to be able to reply for the masq'd internal
> > LAN?
> 
> If you're talking about dnscache, you create a zero length file in the
> dnscache ip directory, with the name of the network you want dnscache to
> service.  If you're using 10.1.2.0/24, you'd run:
> 
> touch /etc/dnscache/root/ip/10.1.2
> 
> and dnscache would answer queries from any system with the IP 10.1.2.x
> 
> Charles Steinkuehler


Ok.  That's how you tell it which network to
respond to with answers.

My question, however, is one level deeper than
that.  Specifically, when the dnscache gets a
request from one of those 10.1.2 computers to
resolve it's neighbor's ip address into a name,
for whatever tcpwrappers etc reason, what happens?

Doesn't it then go to the net and look for 
10.1.2.x. which is bogus?

Here's the opposite direction lookup, name to ip, 
how that might come about:

  1)  You have dnscache running on a computer called "hub"
  2)  Hub masq's an internal private space, like 10.1.2.0/24.
  3)  You have a couple of computers in that private space,
  called "left" and "right"
  4)  You're calling your private domain, myprivateedomainn.net
  5)  All your private computers have their /etc/resolv.conf nameserver
  line pointing to the hub's ip address, as per the directions.
  6)  I sit down at left and type 
 nslookup right.myprivateedomainn.net.
  7)  That sends the request to the hub's dnscache and it's
  needs to get back 10.1.2.2, let's say.



How does it get back 10.1.2.2, if the dnscache is not
authoritative for it's zone, but rather it just caches
answers it gets from the net, and it can't ever get
the correct answer for 10.1.2.2 from the net




These requests lead to dns timeouts and LAN delays.

It's important for whatever dns people decide to run to
be able to resolve their masq'd lan names to addresses.

I don't think that all programs check /etc/hosts.
I don't think /etc/hosts is the correct answer here.

Apologies for the longish post.  It's been bugging me.
Matt

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

Re: [Leaf-user] Oxygen release question

[Matthew Schalit]

David Douthitt wrote:
> 
> Matthew Schalit wrote:
> >
> > I was looking at the leaf site for the
> > lastest Oxygen release, and found that
> > things have been stable for a few months
> > with the libc-2.0.7 and libc-2.1.3 release
> > flavors.
> 
> Development of the 2.0.7 version has basically been stopped

Ok.  That's what I thought.  I still like 051401.  
It's a good 2.0.7 release.  I think you called it 
May 2001.



> The latest images have moved glibc into a glibc.lrp package - so
> physically putting glibc 2.2 won't be a problem; fitting it in will be
> :)


Modular is cool.


 
> > I did see the newer development images,
> > like oxygen-090601.ima.  Is that one
> > stable enough to deploy, or are we better
> > of with
> >
> > oxygen-051401.bin
> > oxygen-2.1.3-041601.bin
> 
> oxygen-090601.ima would be a successor in the lineage of the
> oxygen-2.1.3 variant; the 051401 version is likely to be the older
> Oxygen 2.0.7 image.


Ok.  I'll try out 090601.
What are you going to name it?  September 2001?
How about Nine of One?  Heh heh.

Matt

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user

[Leaf-user] Oxygen release question

[Matthew Schalit]

I was looking at the leaf site for the
lastest Oxygen release, and found that
things have been stable for a few months
with the libc-2.0.7 and libc-2.1.3 release
flavors.

I did see the newer development images,
like oxygen-090601.ima.  Is that one
stable enough to deploy, or are we better
of with

oxygen-051401.bin 
oxygen-2.1.3-041601.bin 

Thanks,
Matthew

___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user