[leaf-user] web server proxy (squid.lrp??)
Is there a package for Dachstein CD that can proxy incoming web addresses btw different web servers? incoming web requests get redirected to a specific web server based on the domain name rather than having all the domains on one server using host headers or virtual domains? i.e. domain1.com / domain2.com / domain3.com --- web server 1 domain4.com / domain5.com / domain6.com --- web server 2 I got one ip for my DMZ and have a couple servers in it but I want to use more than 1 server for serving WWW. Thanks Alec --- 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-CD eth3 / DMZ error
actually I'd like to make a correction to this last e-mail. I did some double checking and a lot of rebooting. I *can* access the DMZ from both my internal nets (eth1 and eth3). I can type the private IP address of the DMZ server into the web browser and I have pages come back. But, entering in the Public IP address of the DMZ server into the web browser yeilds no response (from the internal nets). I can ping the public IP from inside the internal net(s). But computers outside my own network(s) can not ping the public IP. The router can ping the additinal IP on the external interface. I replicated this on another Dachstein-CD boot box on another DSL and had line same problem only this one has just the DMZ and the eth1 internal interfaces. sorry for the mis-information but I didn't find this out until I put together a brand new Dachstein CD 1.02 and loaded it on diff computer that I am building. Thanks Alec -Original Message- From: Charles Steinkuehler [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 11, 2002 10:47 AM To: Alec Miller; [EMAIL PROTECTED] Subject: Re: [leaf-user] Dachstein-CD eth3 / DMZ error ahhh... this is the part that I didn't understand.how to push the packets into the DMZ via the exta eth0 ip addy. sweet thanks.. but now i am finding another issue (hehkeeps getting better and better though) The traffic is going in but not coming back out from within my own private nets (see below). The public can get in...but not me. I am guessing this is another multi-internal net scripting issue?? Hmm...I'm not sure what's going on...what IP are you trying to use to get to the web-server? The public port-forwarded IP (66.93.80.148 ), or the private IP (192.168.2.1)? Exactly what happens when you try connecting with either IP? You may have to wait until I can get a test network setup again, switch to a proxy-ARP based DMZ, or gather some detailed diagnostic information (since my test network is still sitting in the garage, disconnected after my office move at the end of last month). If you want to do the latter, please try the following: - Reboot your firewall to provide a clean slate...you might want even to even dis-connect your upstream link (if you're not using dhclient to configure the external interface) - Log in and manually add some packet tracing ipchains rules: ipchains -I input -l ipchains -I forward -l ipchains -I output -l - Try connecting to your DMZ web-server from both internal networks, using both IP's above (for a total of four different connection attempts). - Run net ipfilter list /tmp/ipfilter.list - Send me the results of the above command, as well as the contents of /var/log/syslog, and the files /etc/network.conf and /etc/ipfilter.conf - Clear your manually added ipchains rules (change the -I to -D in the commands above) or just re-boot. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 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] Dachstein-CD eth3 / DMZ error
I am trying to setup a DMZ with a few extra ips I have. And I can't figure out where I went wrong. My interface configs look like this: eth0_IPADDR=66.93.80.54 eth0_MASKLEN=24 eth0_BROADCAST=255.255.255.0 # Use this to set the default route if required - ONLY one to be set. # routed or gated could be used to set this so only use if not running these. eth0_DEFAULT_GW=66.93.80.1 # Secondary IP addresses/networks on same wire - add them here eth0_IP_EXTRA_ADDRS=66.93.80.148 . eth1_IPADDR=192.168.65.254 eth1_MASKLEN=24 eth1_BROADCAST=192.168.65.255 eth2_IPADDR=192.168.2.254 eth2_MASKLEN=24 eth2_BROADCAST=192.168.2.255 (IPSec WAN interface) eth3_IPADDR=10.72.104.97 eth3_MASKLEN=28 eth3_BROADCAST=10.72.104.111 . INTERN_IF=eth1# Internal Interface INTERN_NET=192.168.65.0/24 10.72.104.96/28 INTERN_IP=192.168.65.254 # IP number of Internal Interface # (to allow forwarding to external IP) MASQ_SWITCH=YES # Masquerade internal network to outside # world - YES/NO DMZ_SWITCH=PRIVATE DMZ_IF=eth2 DMZ_NET=192.168.2.0/24 DMZ_SERVER0=tcp 66.93.80.148 www 192.168.2.1 www DMZ_SERVER1=tcp 66.93.80.148 ftp 192.168.2.1 ftp I also have this line in my ipfilter.conf to allow the eth3 net to get to the eth1 net just after the INTERN_xxx_SERVER lines: $IPCH -A forward -b -j ACCEPT -s 10.72.104.96/28 -d 192.168.65.0/24 Now here is the error I get when i run 'svi network reload'. I have tracked it down to the DMZ_SERVERx list. When I comment them out the error list shrinks. IP filters: /sbin/ipchains: can only specify ports for icmp, tcp or udp Try `/sbin/ipchains -h' or '/sbin/ipchains --help' for more information. /sbin/ipchains: invalid port/service `10.72.104.96/28' specified Try `/sbin/ipchains -h' or '/sbin/ipchains --help' for more information. /sbin/ipchains: invalid port/service `10.72.104.96/28' specified Try `/sbin/ipchains -h' or '/sbin/ipchains --help' for more information. /etc/init.d/network: [B/sbin/ipchains: not found firewall [IP Forwarding: ENABLED] And When I turn the DMZ=NO I have this error: Starting Network: [IP Always Defrag: ENABLED] IP filters: /etc/init.d/network: [B/sbin/ipchains: not found I've been staring at this for hours and can't figure out what is causing it. Thanks In advance Alec --- 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-CD eth3 / DMZ error
I managed to get the 'IP filters: /etc/init.d/network: [B/sbin/ipchains: not found' error gone by replacing the ipfilter.conf and networks file with new ones. but am still have the invalid port service error.before I redo a new network.conf does this bug still exist?? Re: [Leaf-user] 4 NIC LRP -Dachstein CD- only one internal IP forwards to internet http://www.mail-archive.com/leaf-user@lists.sourceforge.net/msg05123.html Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Charles Steinkuehler Sent: Friday, August 09, 2002 1:19 PM To: Alec Miller; [EMAIL PROTECTED] Subject: Re: [leaf-user] Dachstein-CD eth3 / DMZ error Now here is the error I get when i run 'svi network reload'. I have tracked it down to the DMZ_SERVERx list. When I comment them out the error list shrinks. IP filters: /sbin/ipchains: can only specify ports for icmp, tcp or udp Try `/sbin/ipchains -h' or '/sbin/ipchains --help' for more information. /sbin/ipchains: invalid port/service `10.72.104.96/28' specified Try `/sbin/ipchains -h' or '/sbin/ipchains --help' for more information. /sbin/ipchains: invalid port/service `10.72.104.96/28' specified Try `/sbin/ipchains -h' or '/sbin/ipchains --help' for more information. /etc/init.d/network: [B/sbin/ipchains: not found firewall [IP Forwarding: ENABLED] And When I turn the DMZ=NO I have this error: Starting Network: [IP Always Defrag: ENABLED] IP filters: /etc/init.d/network: [B/sbin/ipchains: not found I've been staring at this for hours and can't figure out what is causing it. Thanks In advance It's hard to say exactly what's wrong, but I think one (or more) of the files used to configure networking firewall rules has gotten corrupted...possibly a dos/unix EOL mis-match, or perhaps an incorrect/unrecognized eschape character sequence in a remote editor window (it sure looks like the [B got accidentally added before /sbin/ipchains, to create the last error above, and there could be other hidden problems). It looks like you've got the DMZ configuration variables set correctly, so I'd try running a DOS-unix EOL converter, looking through the configuration files manually, and/or possibly copying them from a fresh Dachstein image and re-configuring network.conf. FYI, files involved in setting up networking/firewalls, and hence possibly causing errors if corrupted include: /etc/init.d/network /etc/network.conf /etc/ipfilter.conf /etc/ipchains.* You can do the dos2unix conversion with your favorite tool/editor on a remote system (move files via ssh/scp/floppy/whatever), or directly on the firewall with sed (requires crafty shell quoting) or something like charconv (available from my site: http://lrp.steinkuehler.net/files/packages/Utilities/charconv ). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) --- 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 --- 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-CD eth3 / DMZ error
OK, That change seems to have removed the /sbin/ipchains: invalid port/service `10.72.104.96/28' error I am getting this error now: IP filters: /sbin/ipchains: can only specify ports for icmp, tcp or udp Try `/sbin/ipchains -h' or '/sbin/ipchains --help' for more information. and these denys: Packet log: forward DENY eth2 PROTO=6 10.72.104.98:1559 192.168.2.1:80 Packet log: forward DENY eth2 PROTO=6 192.168.65.12:3590 192.168.2.1:80 when I type in the URL to the host in the DMZ. I am guessing I have misconfig in the network.conf that blocks traffic into the DMZ from the eth0_IP_EXTRA_ADDRS? (which I never figured out from the start) Thanks again, Alec -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Charles Steinkuehler Sent: Friday, August 09, 2002 4:01 PM To: Alec Miller; [EMAIL PROTECTED] Subject: Re: [leaf-user] Dachstein-CD eth3 / DMZ error I managed to get the 'IP filters: /etc/init.d/network: [B/sbin/ipchains: not found' error gone by replacing the ipfilter.conf and networks file with new ones. but am still have the invalid port service error.before I redo a new network.conf does this bug still exist?? Re: [Leaf-user] 4 NIC LRP -Dachstein CD- only one internal IP forwards to internet http://www.mail-archive.com/leaf-user@lists.sourceforge.net/msg05123.htm l Yes, I believe this bug still exists (at least it's still in the latest Dachstein release I'm running)...good job finding this on the mailing list...I'd forgotten about that bug, and my development server with the todo bug lists is still off-line after my big office move at the end of last month : Anyway, if you want to continue to use a private DMZ (your other option would be Static-NAT or Proxy-ARP), you can play guinea pig and try the following... You'll need to change the DMZ_reverse_masq procedure in /etc/ipfilter.conf...it's got the only reference to INTERN_IF in the whole file, so it's easy to find. Find the following lines which provide reverse-masquerading for port-forwarded DMZ connections when accessed from the internal network: # For internal connections $IPCH -A forward -j MASQ -p $1 -s $DMZ_NET $DST_PORT \ -d $INTERN_NET -i $INTERN_IF Change to the following to support multiple internal networks: # For internal connections for NET in $INTERN_NET; do $IPCH -A forward -j MASQ -p $1 -s $DMZ_NET $DST_PORT \ -d $NET done; unset NET This change should allow multiple internal networks with a private DMZ. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) --- 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 --- 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-CD eth3 / DMZ error
oh, and I started out from scratch with a new network.conf too. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Charles Steinkuehler Sent: Friday, August 09, 2002 4:01 PM To: Alec Miller; [EMAIL PROTECTED] Subject: Re: [leaf-user] Dachstein-CD eth3 / DMZ error I managed to get the 'IP filters: /etc/init.d/network: [B/sbin/ipchains: not found' error gone by replacing the ipfilter.conf and networks file with new ones. but am still have the invalid port service error.before I redo a new network.conf does this bug still exist?? Re: [Leaf-user] 4 NIC LRP -Dachstein CD- only one internal IP forwards to internet http://www.mail-archive.com/leaf-user@lists.sourceforge.net/msg05123.htm l Yes, I believe this bug still exists (at least it's still in the latest Dachstein release I'm running)...good job finding this on the mailing list...I'd forgotten about that bug, and my development server with the todo bug lists is still off-line after my big office move at the end of last month : Anyway, if you want to continue to use a private DMZ (your other option would be Static-NAT or Proxy-ARP), you can play guinea pig and try the following... You'll need to change the DMZ_reverse_masq procedure in /etc/ipfilter.conf...it's got the only reference to INTERN_IF in the whole file, so it's easy to find. Find the following lines which provide reverse-masquerading for port-forwarded DMZ connections when accessed from the internal network: # For internal connections $IPCH -A forward -j MASQ -p $1 -s $DMZ_NET $DST_PORT \ -d $INTERN_NET -i $INTERN_IF Change to the following to support multiple internal networks: # For internal connections for NET in $INTERN_NET; do $IPCH -A forward -j MASQ -p $1 -s $DMZ_NET $DST_PORT \ -d $NET done; unset NET This change should allow multiple internal networks with a private DMZ. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) --- 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 --- 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] looking for TinyDNS zone transfer package
anyone know where I can find a axfrdns package for TinyDNS that I can use with Secondary.com?? or know a secondary name service I can use with TinyDNS.lrp ? thanks Alec Miller --- Sponsored by: ThinkGeek at http://www.ThinkGeek.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
[leaf-user] traffic load balancing (again) from a Dachstein box?
I've got 2 Speakeasy DSL lines both on the same Subnet/Gateway.Are there any FAQ/Quick links I can poke around at (that are up and running) that I can use for attempting a traffic balancer from a Dachstein box? OR should I move to another release? I've got a couple WWW servers I want to throw into my DMZ and I haven't called SE yet to check if they will turn on their equipment for me to pull this off. I want to read up on this before I make any phone calls. I saw a couple links posted previously in the list, but some of them seem to be broken.. thanks ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink 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] NT networking over LEAF IPSEC VPN
I telecommute thru my FreeSwan VPN from Chicago to Detroit. I set up a Win2k server here that runs WINs and replicates at something like 12am to me only (a Pull replication). I only need to do it once or 2x day. I logon to my own network here and can use the shared folders in Detroit. I can also logon to the domain network in Detroit without any problems. You can try using 'Kixstart' to launch all the drive mappings when you logon. The only speed issues I see are from the saturated T1 in Detroit (some 300 ppl trying to access the internet at the same time with Lotus Notes clients replicating every morning). I am using a Dell Optiplex P133 and the other end is a Raptor box (PIII something or other). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Charles Steinkuehler Sent: Friday, April 19, 2002 5:09 PM To: Brock Nanson; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: RE:[Leaf-user] NT networking over LEAF IPSEC VPN I may have been one of those who replied on the FreeS/WAN list. Your posting has actually prompted me to revisit the whole issue. In brief, I think I said that the transfer speeds were fine so long as WINS and browsing was left out of the equation. At least that seems to be the case. However, as you know, this precludes using network neighbourhood. Do you need free run of network neighbourhood, or could you get by with several mapped drives? These could be done automagically with a logon script. I see *GIGANTIC* differences in access speed when browsing to network resources vs using mapped drives. Mapping a drive makes the performance *MUCH* better. I have yet to do any qualitative tests, but user experience indicates a 10x to 100x type of improvement. This could easily be the result of a sub-optimal network configuration on my part (I'm not a particularly good Windows admin, and don't particularly want to be...I know just enough to keep my system running). Please keep the list informed of your progress with this... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Morpheus?
I don't quite understand it myself. I was downloading some MP3's and within an hour of using it I find that I had people downloading those same MP3's from me. I thought you needed to open ports and point the forwarding rules to your desktop. So I am not sure how it was able to allow other users to download from you. You *can* turn off sharing files to other users within Morpheus, but I don't think that will totally block the holes in it. - Original Message - From: Steve Jeppesen [EMAIL PROTECTED] To: [EMAIL PROTECTED]; leaf-user [EMAIL PROTECTED] Sent: Sunday, February 24, 2002 9:04 PM Subject: Re: [Leaf-user] Morpheus? if you find a way to safely use it let me know. Both of my daughters use it and I am a bit worried after reading what can happen, ie; ppl have the ability to connect to your hard drive and go from there. Other than that, they both can connect to it ok, and I am using Dachstein CD v1.0.2 On Sun, 24 Feb 2002 21:51:51 -0500 Christopher Holmes [EMAIL PROTECTED] wrote: Anyone know if it's possible to set up a firewall (Dachstein) to safely use Morpheus? Do I need to open a port or something? I searched around on the web suprisingly didn't find much. Chris ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] IPsec error in logs
Anyone know how to get rid of this error in the logs? Running IPSec 1.91 from Charles site on Dachstien CD 1.02. router kernel: ip_demasq_esp(): Inbound from 65.xx.xx.xx SPI EBC4FE83 has no masq table entry Thanks ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Saving IPSec Configuration on DCD...??
did you change the back up options to save to the Floppy? - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 10, 2002 4:49 PM Subject: [Leaf-user] Saving IPSec Configuration on DCD...?? OK, I give up. What is the magic combination for getting the ipsec.conf and ipsec.secrets files to backup with DCD? I am thick, dense, and very frustrated Thanks, Dan ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Tinydns startup error on Dachstien RC1.0.2
How can you tell if Tinydns is running? Weblet shows it was loaded but the running process list only shows dnscache. I tried /etc/init.d/tinydns restart and I get this back in response: tinydns error: tinydns start arg and Clues? and when did Geocrawler become non-searchable? or did I miss some announcement on that change? thanks Alec ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] IPSec 1.9
I've got the Dachstein RC5 up and running and I copied over the configs for IPSec 1.5. I just copied over all the previous configs from 1.5 and everything connects (ipsec manual connection) without any errors that I can see, even poking thru all the debug output shows everything as 'success'. I have left and right firewall = yes and when I type 'route' I can see the routes built for ipsec0. Same with 'Ipsec eroute' shows the correct tunnel routing. But I can't ping any hosts on the remote network. (10.72.104.xx) There is traffic coming to me, but none from me to the remote sitecan any one suggest something that I might have missed? Thanks Inter-| Receive| Transmit face |bytespackets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed lo: 72 1000 0 0 0 72 1000 0 0 0 ipsec0: 205 11060 0 0 00 00 120 0 0 0 ipsec1: 0 0000 0 0 00 0000 0 0 0 ipsec2: 0 0000 0 0 00 0000 0 0 0 ipsec3: 0 0000 0 0 00 0000 0 0 0 brg0: 0 0000 0 0 00 0000 0 0 0 eth0: 9570177 14261000 0 0 0 1523368 13295000 0 0 0 eth1: 1854131 17992000 0 0 0 11674810 18695000 279 0 0 eth2: 143889 957000 0 0 0 111525 1036000 3 0 0 ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] dmzSpoof
sorry... Ok...I've got a C-Strike server on the outside of my network, unmanaged by anything. It is fowarding log files/info from port 27016 to a remote www server on port 2002 inside the NAT'd DMZ. - Original Message - From: Charles Steinkuehler [EMAIL PROTECTED] To: Alec Miller [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, November 16, 2001 8:07 AM Subject: Re: [Leaf-user] dmzSpoof I've got Dachstein RC5 running and trying to put the final touches on it. I've got a Counter-Strike server spitting into to another server inmy DMZ. I've tried to open this port to allow the info to pass thru into the DMZ but for some reason I just can't figure this one out. I've tried opening the port up but. router kernel: Packet log: dmzSpoof DENY eth0 PROTO=17 64.1.132.140:27016 64.1.132.143:2002 More details, please. What sort of DMZ are you trying to setup? In general, the dmzSpoof rule denies packets from the outside world that should have come from the DMZ. If you've got a block of IP's and are running a proxy-arp or static-NAT DMZ, you probably have a problem with DMZ_EXT_ADDRS, which is how the firewall rules know which IP's are on which side of the router. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Dachstein-CD RC4: loading modules -solved
OK.this was definitely one of things you put on your list of Stupid Things I'll never do again. My 1st problem was that I would burn the ISO and then copy it all to my hdd and massage the packages back and forth on the CD-RW. Little did I know that making an ISO image and just plain burning a CD are 2 different things. (I know now!) among some other issues of the LRP packages not backing up correctly for some reason after I poked around with the 'zcat' and comparing the actual files on the floppy versus the CD. (most likely resulting from previous problem) I decided that since I could go to 2 different computers and have the same problem that it was me and not the computer. So I made a clean RC5 ISO burn and the stuff in the Floppy that I spent the last 5 days building and tweaking.booted it up and Viola! Everything worked on the 1st try. I think wasting the 50 cents a CD would have been better than using a CD-RW to start with. I do have to say that after almost a year trying to get the Java BW meter running on LRP and now seeing it in Webletthis Rocks! - Original Message - From: Charles Steinkuehler [EMAIL PROTECTED] To: Alec Miller [EMAIL PROTECTED]; LEAF [EMAIL PROTECTED] Sent: Wednesday, November 14, 2001 8:40 AM Subject: Re: [Leaf-user] Dachstein-CD RC4: loading modules I have no errors that appear in the info prior to the logon. I can use 'insmod' and load the network card drivers by hand off the CD, then everything works. But I can't get them retained in a backup package or on a reboot, they just won't load. anything else I can try? Verify your boot= and pkgpath.cfg settings. Boot= should be the floppy disk, and pkgpath.cfg should list your CD. Verify when the modules package is loaded, it's loading from both the main package from the CD, and your local configuration from the floppy. Unpack modules.lrp on your floppy, and make sure etc/modules contains what you expect. To do this, mount your floppy, cd to /tmp, and run zcat /mnt/modules.lrp | tar -xv. Then edit /tmp/etc/modules and verify it's contents... If there are any problems, edit /etc/modules as desired. Verify it works by running svi modutils start...you will get errors about any modules already loaded, which you can ignore or make go away by removing all modules prior to this test (use rmmod module and lsmod). Once all modules are loading correctly manually, backup modules, making sure you set the backup type to 'partial', and the destination to 'fd0'. If you still can't get things running, the only other thing to try is going back to the 'old' way of loading modules, from /lib/modules instead of directly from the CD. Copy the modules you need to /lib/modules, edit /etc/modules as required (remove the ! commands), and do a FULL backup of modules to your floppy. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Dachstein-CD RC4: loading modules
anyone else got any more hints they can give? I put the pci-scan driver in but it still won't load any network card modules. But it sure seems to load everything else off the CD OK. thanks Alec - Original Message - From: Alec Miller [EMAIL PROTECTED] To: LEAF [EMAIL PROTECTED] Sent: Monday, November 12, 2001 5:43 PM Subject: Re: [Leaf-user] Dachstein-CD RC4: loading modules I think I missed something in the module loading process. I get everything loading in the boot process and its missing loading the modules for the network cards. I am sure its in the module file in \etc but I don't know if I am doing this correctly. I am booting from the floppy to load the CD. I have no HDD so the CD player is ' /hda '. I am sure this is pretty obvious but I am only used to doing dual floppies. All my Nics are PCI or integrated and I have been using the dual floppy version for almost a year. anyone got a clue train ticket to sell me? Why its not loading the modules? thanks Alec ### ! mount iso9660 /dev/hda # You can directly reference modules, like this: #/scsi/aic7xxx #/fs/ext2 # Or change the default directory, like this: ! dir /lib/modules/net # PCI ethernet cards #3c59x rtl8139 3c509 .. !umount ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Dachstein-CD RC4: loading modules
Yup, this is what I currently have..upon boot it loads all LRP packages then tries to init the network cards and then starts claiming that eth0, eth1 doesn't exist and then DHCPd fails (for obviouse reasons). ! mount iso9660 /dev/hda -- this is correct?? Where 'hda' is the CD drive? I know everything works 'cause I can reboot with my current Eiger static floppies and it works fine and under the CD RC4 install I can edit and save any changes with a partial/full backup to the floppy. ## # More modules available from: # http://lrp.steinkuehler.net/files/kernels/ ## # ! mount iso9660 /dev/hda ! mount iso9660 /dev/hda # You can directly reference modules, like this: #/scsi/aic7xxx #/fs/ext2 # Or change the default directory, like this: ! dir /lib/modules/net # PCI ethernet cards #3c59x pci-scan rtl8139 3c509 #eepro io=0x300 ###Some 8390 based ethernet cards #8390 # card1,card2 #ne io=0x300,0x350 #ne2k-pci #e2100 # PCI ethernet cards #pci-scan # pci-scan required by drivers below... #3c59x #eepro100 #natsemi #tulip ! dir /lib/modules/ipv4 ip_masq_autofw ip_masq_cuseeme #ip_masq_dplay ip_masq_ftp #ip_masq_h323 ip_masq_icq ip_masq_ipsec ip_masq_irc ip_masq_mfw #ip_masq_mms ip_masq_portfw #ip_masq_pptp ip_masq_quake ip_masq_raudio ip_masq_user ip_masq_vdolive ! umount - Original Message - From: James Duberg [EMAIL PROTECTED] To: Alec Miller [EMAIL PROTECTED]; LEAF [EMAIL PROTECTED] Sent: Tuesday, November 13, 2001 5:00 PM Subject: Re: [Leaf-user] Dachstein-CD RC4: loading modules You put the pci-scan module before the NIC modules, right? --On Tuesday, November 13, 2001 4:41 PM -0600 Alec Miller [EMAIL PROTECTED] wrote: anyone else got any more hints they can give? I put the pci-scan driver in but it still won't load any network card modules. But it sure seems to load everything else off the CD OK. thanks Alec - Original Message - From: Alec Miller [EMAIL PROTECTED] To: LEAF [EMAIL PROTECTED] Sent: Monday, November 12, 2001 5:43 PM Subject: Re: [Leaf-user] Dachstein-CD RC4: loading modules I think I missed something in the module loading process. I get everything loading in the boot process and its missing loading the modules for the network cards. I am sure its in the module file in \etc but I don't know if I am doing this correctly. I am booting from the floppy to load the CD. I have no HDD so the CD player is ' /hda '. I am sure this is pretty obvious but I am only used to doing dual floppies. All my Nics are PCI or integrated and I have been using the dual floppy version for almost a year. anyone got a clue train ticket to sell me? Why its not loading the modules? thanks Alec ### ! mount iso9660 /dev/hda # You can directly reference modules, like this: # /scsi/aic7xxx # /fs/ext2 # Or change the default directory, like this: ! dir /lib/modules/net # PCI ethernet cards # 3c59x rtl8139 3c509 .. !umount ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Dachstein-CD RC4: loading modules
I think I missed something in the module loading process. I get everything loading in the boot process and its missing loading the modules for the network cards. I am sure its in the module file in \etc but I don't know if I am doing this correctly. I am booting from the floppy to load the CD. I have no HDD so the CD player is ' /hda '. I am sure this is pretty obvious but I am only used to doing dual floppies. All my Nics are PCI or integrated and I have been using the dual floppy version for almost a year. anyone got a clue train ticket to sell me? Why its not loading the modules? thanks Alec ### ! mount iso9660 /dev/hda # You can directly reference modules, like this: #/scsi/aic7xxx #/fs/ext2 # Or change the default directory, like this: ! dir /lib/modules/net # PCI ethernet cards #3c59x rtl8139 3c509 .. !umount ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Is anybody using radmin behind lrp?
there are several flavors of VNC. even spyware VNC. http://www.tridiavnc.com/news/time_response.html I don't remember exactly what they did with this version, but I think it has better compression than the ATT version. http://www.tridiavnc.com/ - Original Message - From: Hilton Travis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 10, 2001 5:54 PM Subject: RE: [Leaf-user] Is anybody using radmin behind lrp? -Original Message- From: Patrick Benson [mailto:[EMAIL PROTECTED]] Sent: Thursday, 11 October 2001 08:31 Hilton Travis wrote: Hi Patrick, The advantage of RAdmin over vnc is that it is much lighter on traffic. Using vnc over a modem is much slower than using RAdmin over a modem. RAdmin has zero cross-platform functionality, however, and vnc is needed for cross-platform users. I have used RAdmin for a coupla years now, and have found it to be an excellent product if used on a Wintel-only platform. It also has 128-bit encryption, or so the docs say, but I am not sure how secure this is as I do not use it across the 'Net. As for port-forwarding thru LEAF, I have not set this up yet, so unfortunately cannot help you here, Kim. vnc = good, RAdmin = good. :-) Regards, Hilton Points well taken, Hilton! :-) Do you have any idea why RAdmin is lighter on traffic over a modem? Sounds pretty interesting... -- Patrick Benson Stockholm, Sweden Hi Patrick, Just is. Like NetBEUI is lighter than TCP/IP. They either compress the data better than vnc does, or they use some other way to transmit less data. Have a look at a traffic moniotor when u r running either app, and you'll notice RAdmin uses a lot less network bandwidth. ESPECIALLY so compared to PCAnywhere. :-) But, anyone who seriously uses PCAnywhere needs to be beaten to death with a hundred plastic teaspoons. Regards, Hilton Travis ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] LaBrea for LRP?
Someone sent me this link in the midst of the recent Nimda attacks. I don't have the tools to make this into an LRP package, but I think this could be a neat addon. (If it doesn't already exist for LRP) Alec = http://www.incidents.org/LaBrea/LaBrea.txt Welcome to My Tarpit The Tactical and Strategic Use of LaBrea Introduction LaBrea is a small Linux-based application that puts unused IP addresses on your network to use, creating a tarpit which can stop or slow down scans of your address space. This paper details the technical aspects of how LaBrea works as well as the tactical advantages of deploying LaBrea on your network. Background - Creating Virtual Machines -- LaBrea works as a low-level network application that creates virtual machines on your network - machines that don't really exist yet are able to answer connection attempts in a special way that slows and even stops the connecting process. Local communication between machines on a LAN (local area network) is done using MAC (machine access code) addresses, not with IP addresses. These MAC addresses are 48 bits in length, as opposed to the 32 bits of an IP address. External attempts to access machines in the LAN are done using IP addresses and will go through the local router. The local router's job is to figure out which MAC corresponds to which IP. The router does this by broadcasting a special request asking who owns the IP in question. If any machine owns the IP it will respond with its MAC address to the router. This request and response is known as the Address Resolution Protocol or ARP. The tenacious quality of the ARP protocol used in these router requests is what makes LaBrea possible: If at first the router does not find a machine with the IP in question, it will ask again - and again. LaBrea monitors these ARP requests and replies that are needed to connect external traffic with the local area network. If it notes several successive ARP requests without intervening ARP replies LaBrea will issue an ARP reply, effectively creating a virtual machine. Making Virtual Machines Real Once the virtual machine has been created, LaBrea will monitor all traffic destined for the MAC address it has given to the router, and will thereafter respond to inbound TCP/IP packets in a way that can tie up the connecting machines for long periods of time. Most modern TCP/IP implementations are very tenacious about holding onto established connections. LaBrea sends enough of a response to hold the connection open, but no more - the connecting machine is left hanging, waiting. Tarpitting -- The connecting machine's TCP/IP implementation will ordinarily not give up easily, but will continue to attempt to use what it regards as an established connection over and over until it finally times out. The timeout value will of course vary from implementation to implementation, but it will always be several orders of magnitude longer than for a failed connection attempt. This is the tarpit that LaBrea uses to catch worms and scanners. Connection Trapping --- LaBrea can also trap and hold connection attempts. By moving a connection from the established state to the persist state, LaBrea can literally hold connections open for an indefinite period of time, so that only a process reset at the other end will end it. Communicating in this manner is done economically despite the potentially wide bandwidth involved; also, the bandwidth usage itself is configurable. Impersonation - To effectively trick more advanced scanning tools into believing virtual machines are real, LaBrea offers standard responses to a number of typical network probes such as echo requests and SYN/ACK scans. No Collateral Damage All connection attempts aimed at LaBrea virtual machines can be considered suspect in nature as these machines do not really exist nor do they, for example, have any entries in the Domain Name System. Tactical Use Monitoring connection activities can give the network operations center a good view of the extent and nature of any reconnaissance taking place: Is a broad range of addresses being targeted, or do you have a focused intrusion attempt? LaBrea also makes an excellent adjunct to other early warning systems. Correlating intrusion detection system warnings with LaBrea virtual machine access records helps you immediately gauge the severity of an intrusion attempt. An intrusion attempt aimed solely at real machines should of course be put at a higher
Re: [Leaf-user] echowall 1.3 released
FYI -- Remember that the HL engine will only use Public IP addresses in order to be seen in a Game browser. (GameSpy, or the HL server browser) You can still launch the server but you will have to post the External IP somewhere (webpage,e-mail) that will forward the packets to the internal IP so people can connect to it. the +ip option is if you have Multiple Nics/IPs on the same machine (or Nic) so you can bind the game to that specific Nic or IP. It will not work if the IP does NOT exist on that machines Nics. - Original Message - From: DPG [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 11, 2001 12:44 AM Subject: FW: [Leaf-user] echowall 1.3 released There is a command line variable for the HL server to explicitly state the IP address. The shortcut that starts your server should look something like this: PathToHalf-LifeDircectory\hlds.exe -game cstrike +ip your IP here +maxplayers 10 Or, when you lose your baby teeth, and move up to Linux grin, it will look like this: ./hlds_run -game cstrike +ip your IP here +maxplayers 10 All the goods on server admin are here: http://server.counter-strike.net/howto.html Makes me miss the old days, before Speakeasy moved my POP 800 miles further down the copper, and raised my gateway ping from 20 to 100 ms. That move put my servers out of business. :( Now I just have an expensive, high-latency SDSL line but no servers... Did I mention Speakeasy is off my holiday greeting card list? D -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott C. Best Sent: Monday, September 10, 2001 9:58 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Leaf-user] echowall 1.3 released Mark: Heya. This sounds like it's either an interface problem, or a problem with the CounterStrike server setup. In echowall.conf, did you choose ppp0 or eth0 for IF_EXT? For PPPoE, I believe it should be the first one. The 169.254.0.0/16 address you speak about is actually what a DHCP client will default to if a valid DHCP server doesn't give it a lease when it asks for one. AFAIK, it shouldn't be a usable address, so I'm confused where you're seeing it. Just in the CStrike server, or do you see it in ip addr show? Finally, perhaps there's a config setting in the CStrike server, telling it whether to use static or DHCP addresses? I could imagine that the server itself is asking for an DHCP lease unless you tell it not to. Sorry that I don't know the particulars of this server setup any better... Lemme know what you find out! cheers, Scott I am trying to get a CounterStrike server going using this release. The firewall seems to work and the new additions to the services are great. The problem is, when I start the server, it keeps trying to use a 169.254.*.* IP address which is the bogus address assigned by Windows when one is not found. This is the address of my WAN Adapter, and if I disable it, the server then tries to use the Internal Ip address of my LAN Adapter...both of which are not seen from outside of the firewall. I know the external IP address...but I use PPPoE, and am using Kenneth Hadley's PPPoE package. I added HLIFE to the Wanted Services, and added the MAC Address for the machine acting as the server, and it shows the services directed to the correct machine (when starting Echowall), using the correct Internal IP address. Any ideas what I am missing? Any help would be appreciated. ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Could the CPU fan removed?
Same thing. Dell Optiplex P133 with a large heatsink..In my naturally cooled 60 degree (F) basement. the only thing left cooling it is the Power supply fan. - Original Message - From: Peter Nosko [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 09, 2001 2:27 PM Subject: RE: [Leaf-user] Could the CPU fan removed? Binh Do asked: This sounds rather hardware-ish but I am talking about the machine running LRP with one floppy so just wonder if any of you have done that and if is it safe? The machine is Pentium 233-MMX, Asus motherboard. pn] I've done this with a P-100, and the Dell Optiplex machines I have run a P-166 with only a large (very large) heat sink. --- Peter Nosko _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Leaf-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-user ___ Leaf-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-user
