[leaf-user] Bering-uClibc 2.1.3 Stops after Several Hours Part #2
I built a new LRP yesterday with a newer motherboard, two PCI cards, and 128 megabytes of RAM. Bering-uClibc_2.1.3 ran fine for several hours, but stopped sometime overnight. The problem does not appear to be with the old ISA NICs. The system is back and running with Dashstein. After 7 hours, I have the following firewall status message You have 1092 denied or rejected packets in your recent packet logs. This is not an unusual number for my system but Dashstein continued to run and I did not worry about it. Perhaps I should have. Does Bering-uClibc 2.1.3 handle denied or rejected packets in a way that will cause Shorewall to stop? Thanks in advance for your help. --- Forwarded message follows --- From: mcartter at pol dot net To: [EMAIL PROTECTED] Date sent: Sat, 10 Jul 2004 17:27:02 -0400 Subject:Bering-uClibc_2.1.3 stops after several hours Priority: normal Problem: Bering-uClibc_2.1.3 stops after several hours. I have been using the Dachstein_contributed pppoe version by Kenneth Hadley on a home network for the past two years without any problems. The LRP is connected to three PCs running Windows XP professional via a switch. The LRP runs on a 486 with two ISA cards: eth0 uses 8390.o and ne.o; eth1 uses 3c509.o. I decided to upgrade to Bering-uClibc_2.1.3. I have been able to get the system up and running with no error messages. I am able to monitor the status via Mozilla browser and weblet. After several hours, the firewall status turns to error (more than 50 denied packets). Not long after, I lose the connection to the Internet on one or more PCs, and the connection to the internal network is down on all three PCs. This afternoon, I had one PC still connected to the Internet, but was unable to see the other two PCs on the network. When I restart using the Dashstein disk, the system works fine. I have searched the old mail lists and found a report by one user that was somewhat similar and may have been due to a driver problem using the old 3Com ISA card (there was no follow up to that message. Before I start pulling cards, I would appreciate any insight that the users of this list have into this problem. I have pasted the various messages below: * the exact name of the LEAF distribution and version you are running. Bering-uClibc_2.1.3 * the exact kernel version you are running ash# uname -a Linux firewall 2.4.24 #3 Sun Feb 22 19:25:40 CET 2004 i486 unknown cp /var/log/messages /mnt/messages.txt Jul 10 10:52:07 firewall syslogd 1.4.1: restart. Jul 10 10:52:07 firewall kernel: klogd 1.4.1, log source = /proc/kmsg started. Jul 10 10:52:07 firewall kernel: No module symbols loaded. Jul 10 10:52:07 firewall kernel: BIOS-provided physical RAM map: Jul 10 10:52:07 firewall kernel: 16MB LOWMEM available. Jul 10 10:52:07 firewall kernel: DMI not present. Jul 10 10:52:07 firewall kernel: Initializing CPU#0 Jul 10 10:52:07 firewall kernel: Memory: 14252k/16672k available (995k kernel code, 2032k reserved, 99k data, 80k init, 0k highmem) Jul 10 10:52:07 firewall kernel: Dentry cache hash table entries: 4096 (order: 3, 32768 bytes) Jul 10 10:52:07 firewall kernel: Inode cache hash table entries: 2048 (order: 2, 16384 bytes) Jul 10 10:52:07 firewall kernel: Mount cache hash table entries: 512 (order: 0, 4096 bytes) Jul 10 10:52:07 firewall kernel: Buffer cache hash table entries: 1024 (order: 0, 4096 bytes) Jul 10 10:52:07 firewall kernel: Checking 'hlt' instruction... OK. Jul 10 10:52:07 firewall kernel: Linux NET4.0 for Linux 2.4 Jul 10 10:52:07 firewall kernel: Based upon Swansea University Computer Society NET3.039 Jul 10 10:52:07 firewall kernel: Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ DETECT_IRQ SERIAL_PCI enabled Jul 10 10:52:07 firewall kernel: ttyS00 at 0x03f8 (irq = 4) is a 16550A Jul 10 10:52:07 firewall kernel: ttyS01 at 0x02f8 (irq = 3) is a 16550A Jul 10 10:52:07 firewall kernel: Real Time Clock Driver v1.10e Jul 10 10:52:07 firewall kernel: Floppy drive(s): fd0 is 2.88M Jul 10 10:52:07 firewall kernel: FDC 0 is a National Semiconductor PC87306 Jul 10 10:52:07 firewall kernel: Initializing Cryptographic API Jul 10 10:52:07 firewall kernel: NET4: Linux TCP/IP 1.0 for NET4.0 Jul 10 10:52:07 firewall kernel: IP Protocols: ICMP, UDP, TCP, IGMP Jul 10 10:52:07 firewall kernel: IP: routing cache hash table of 512 buckets, 4Kbytes Jul 10 10:52:07 firewall kernel: TCP: Hash tables configured (established 1024 bind 1024) Jul 10 10:52:07 firewall kernel: NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Jul 10 10:52:07 firewall kernel: RAMDISK: Compressed image found at block 0 Jul 10 10:52:07 firewall kernel: Freeing initrd memory: 284k freed Jul 10 10:52:07 firewall kernel: Freeing unused kernel memory: 80k freed Jul 10 10:52:08 firewall kernel: ne.c:v1.10 9/23/94 Donald Becker ([EMAIL PROTECTED]) Jul 10 10:52:08 firewall kernel: Last modified Nov 1, 2000
[leaf-user] ANN: ML Outage
Everyone, It seems we just had a global mailing list issue. If you posted a message in the last couple of days, please check to see if it actually posted to our mailing lists. Thanks. Check the archive for your post. http://sourceforge.net/mail/?group_id=13751 -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.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] Weird Proxy Arp Setup
Ok, First I want to thanks everyone for their responses so far! I will stop being ambigious, since it seems to make things more complicated and I think where i work probably has the whole 138.23.0.0/16 block anyways so that secret is already out... My address are on the 138.23.75.0 and 138.23.76.0 subnets. I have been trying to narrow down the problem with the machine that was unreachable in the dmz, so I removed the multiple addresses from the eth0 interface on the leaf box and currently only have 1 machine in the dmz. Currently for testing I am using the following setup... LEAF eth0=138.23.75.52 mask 255.255.255.0 LEAF eth1=192.168.1.1 Machine in dmz=138.23.75.60 mask 255.255.255.0 The leaf box is able to ping the machine in the dmz and the machine in the dmz can ping the leaf box. So everything between these two machines seems great. Route shows up for 138.23.75.60 via eth1. However, when I try to ping the machine in the dmz from another machine, there is no luck (shorewall has been set to allow pings and there is nothing in the log). Also the machine in the dmz can ping nothing outside of the leaf box. Now, if I give the same machine in the dmz the address I used for the machine that did work before (138.23.76.112 mask 255.255.255.0) everything works beautifully! The 138.23.76.112 address in the dmz works if the LEAF eth0 interface is assigned an address in the 138.23.75 or the 138.23.76 subnet too, so I guess that is not an issue after all. So right now I am baffled. If I plug the machine in the dmz directly into the network with the 138.23.75.60 address it works fine. Am I going mad, or is there something that would cause this behavior? Many Thanks, Ryan At 04:52 PM 7/10/2004 -0700, Ryan Rich wrote: Hello, I have a question regarding the setup of proxy arp... I think my situation is a little strange so let me explain, I do not consider myself a network expert so fogive me if I am a little off with my terminology... We have a physical network that contains 2 logical subnets, 138.23.aa/24 and 138.23.bb/24 (i.e. I can assign a machine address 138.23.aa.xx (mask 255.255.255.0) or 138.23.bb.xx (mask 255.255.255.0) and plug them into the same jack and they will both work). I have a few servers I would like to firewall using proxy arp. Some of the machines have an address on the 138.23.aa network and some on the 138.23.bb. Now this works fine if I assign the LEAF machine an IP address in the 138.23.aa network (eth0) and the server's address in my dmz (eth1) is also in the same subnet (138.23.aa)... but when I try to add a server with an address from the 138.23.bb network to my dmz, it is unreachable (even though if I were to plug this machine into the very same physical connection with that address it would work). Now after doing a little reading about proxy arp it looks like this would be normal behavior... So I do have an extra address in the 138.23.bb network so I tried adding it as an alias to the eth0 interface (eth0:0) in hopes that I would then be able to proxy arp to my servers with both the 138.23.aa and 138.23.bb addresses. I have had no luck as of yet though, the aliased address on the leaf box interface is pingable and reachable, but it still won't proxy arp to the machine in the dmz with the 138.23.bb address. I have tried changing the broadcast in the shorewall config from detect to 138.23.aa.255,138.23.bb.255 but no dice. I have gone through the shorewall documentation and read about aliasing, but I don't see anything that is similiar to my situation. Does anyone have any suggestions on how to go about making this work or is it just too wierd to have a network like this? First, a blue sky thought here. I mention it only because you emphasized that you are not a networking expert. (Also, your i.e. is ambiguous in a way that is exactly relevant to this possibility, and your comment about changing the broadcast address also suggests it.) Is it possible that aa and bb are sequential values (for example, 20 and 21) of a sort (even-odd, not odd-even) that would let you use the representation 138.23.aa.0/23 for the network? If so, you can probably modify the LEAF router's settings to treat everything as a single network. And then 138.23.bb.255 is the correct broadcast address. If that approach can't be used ... Tom already answered about the 1-external address situation. But it remains unclear why you can't proxy arp if both networks appear on the external interface. Did you verify that you set this part up correctly ... for example, does the LEAF router's routing table have entries for both 138.23.aa.0/24 and 138.23.bb.0/24? Do the DMZ hosts on 138.23.bb.0/24 and the LEAF router themselves communicate properly? --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no
Re: [leaf-user] Weird Proxy Arp Setup
Ryan Rich wrote: Ok, First I want to thanks everyone for their responses so far! I will stop being ambigious, since it seems to make things more complicated and I think where i work probably has the whole 138.23.0.0/16 block anyways so that secret is already out... My address are on the 138.23.75.0 and 138.23.76.0 subnets. I have been trying to narrow down the problem with the machine that was unreachable in the dmz, so I removed the multiple addresses from the eth0 interface on the leaf box and currently only have 1 machine in the dmz. Currently for testing I am using the following setup... LEAF eth0=138.23.75.52 mask 255.255.255.0 LEAF eth1=192.168.1.1 Machine in dmz=138.23.75.60 mask 255.255.255.0 The leaf box is able to ping the machine in the dmz and the machine in the dmz can ping the leaf box. So everything between these two machines seems great. Route shows up for 138.23.75.60 via eth1. However, when I try to ping the machine in the dmz from another machine, there is no luck (shorewall has been set to allow pings and there is nothing in the log). Also the machine in the dmz can ping nothing outside of the leaf box. Now, if I give the same machine in the dmz the address I used for the machine that did work before (138.23.76.112 mask 255.255.255.0) everything works beautifully! The 138.23.76.112 address in the dmz works if the LEAF eth0 interface is assigned an address in the 138.23.75 or the 138.23.76 subnet too, so I guess that is not an issue after all. So right now I am baffled. If I plug the machine in the dmz directly into the network with the 138.23.75.60 address it works fine. Am I going mad, or is there something that would cause this behavior? You might be going mad (hard to tell from a couple of e-mails!), but there's almost certainly something causing the observed behavior. I can't tell you exactly what given the nearly complete lack of diagnostic information, but I'll try to get you headed in the right direction. First, let's get some details out of the way: - It sounds like you only have an upstream (eth0) and dmz (eth1) interface on your Bering box...is that correct? - You have two subnets connected to the upstream interface of your firewall: 138.23.75.0/24 and 138.23.76.0/24, correct? - You want to put externally visible IP's from both subnet ranges on a proxy-arp DMZ connected to eth1 of your firewall, correct? OK, assuming all of the above is accurate, you need to setup the following: - eth0 should be configured with: * An IP address on both subnets * A local route to each subnet * A default route to your upstream gateway * Proxy-arp enabled - eth1 should be configured with: * An IP address on both subnets (different IP's than used for eth0) * A host route for each public IP to make visible upstream * Proxy-arp enabled You can verify this setup (and report diagnostics to the list) with the following commands: ip addr list ip route list for i in /proc/sys/net/ipv4/conf/*/proxy_arp ; do echo $i: ; cat $i ; done Once this is setup correctly, and you have no firewall rules in place (either totally disable firewalling, or allow any-to-any in shorewall), you should be able to communicate between DMZ systems and the internet (or the network on the upstream side of the firewall). NOTES: - You can setup eth0 and eth1 manually, using /etc/network/interfaces, or whatever suits your fancy. It's probably easiest to test by setting up manually, but make sure you dump the config (using the above diagnostic commands) once you get everything working, so you can then add extentions to ifup/ifdown to match. - DMZ systems can use either the IP of the DMZ interface of your firewall, or the same default gateway as the firewall itself. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.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 1.2 CD won't load daemontl.lrp
Hello Richard Are you sure that dnscache is really running over daemontools. You should set up the /service directory as stated in the cr.yp.to page. so multilog can use the settings there. didn't try it myself on bering, ( only in debian) you should have processes with supervise .log and the running process. Regards eric Wolzak member of the Bering Crew I am attempting to boot *everything* from Bering 1.2 CD, rather than using CD plus helper floppy. This is to teach a class in the fall using Bering and distribute only CDs to the students. I am including so many lrps -- ipsec, daemontl, etc -- that I am over the 254 char line limit on syslinux.cfg. So, I transition to using leaf.cfg to load the extra modules i.e. changed the LEAFCFG as follows in syslinux.cfg: display syslinux.dpy timeout 0 default linux initrd=initrd.lrp init=/linuxrc rw root=/dev/ram0 LEAFCFG=/dev/cdrom:iso9660 PKGPATH=/dev/fd0:msdos,/dev/cdrom:iso9660 syst_size=12M log_size=4M LRP=root,etc,local,modules,iptables,pump,keyboard,shorwall,ulogd,dnscach e,ipsec,mawk,dhcpd I have the above syslinux.cfg and following leaf.cfg files injected into bootdisk.bin using winimage. I save the bootdisk.bin file with winimage, and burn a CD. The CD boots fine, and all other functions from the syslinux.cfg LRP= load, plus weblet from leaf.cfg. But I get no daemontl to log dns. (/etc/dnscache/env/QUERYLOG is set to YES) The verbose flag in leaf.cfg seems to put no additional lines in any file in /var/log... Curiouly, (but harmlessly) no initrd in the packages menu of lrcfg, although I can see initrd loading when the machine boots up. What could be wrong? TIA Rick. # This file is parsed as a shell script # Kernel command line paramters are avaialble as KCMD_variable # ie: KCMD_LRP contains the LRP= portion of the kernel command line # NOTE: For kernel command line settings that do not include an equals # sign (ie: rw or similar), the variable is set to itself, allwoing # for easy testing (ie: KCMD_rw=rw). # LRP and PKGPATH variables now support whitespace (space, tab, newline) # as well as commas for seperators. # Uncomment for more verbose execution. VERBOSE=1 # Other variables you might want to set in this file include: # LRP Packages to load # PKGPATH Device(s) to load packages from # syst_size Size of root ramdisk # tmp_sizeSize of /tmp ramdisk # log_sizeSize of /var/log ramdisk # Example: LRP=$KCMD_LRP rsync LRP=$KCMD_LRP daemontl LRP=$KCMD_LRP weblet --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.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 --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.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] Upgrading uClibC 2.1.0 to 2.2.0b4 with HDD boot.
Hi Everyone. I have an existing 2.1.0 system in place that boots from an HDD. I am trying to upgrade to 2.2.0b4. I created a new initrd.lrp package with the modules for 2.4.26 kernel and copied it to the HDD. I copied the linux kernel from the 2.2.0b4 floppy to the HDD. I get this error: VFS: Can't find a Minix, or Minix V2 filesystem on device 03:01 It does find the HDD during the boot sequence. What does work? I can boot the initrd.lrp plus linux kernel off floppy and manually mount the HDD. Other things I have tried: I tried to use the floppy and change the syslinux.cfg to PKGPATH=/dev/hda1 to load the packages, but that doesn't work. Any ideas on how to solve this? Thanks, Geoff --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.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] Weird Proxy Arp Setup
Ryan Rich wrote: So right now I am baffled. If I plug the machine in the dmz directly into the network with the 138.23.75.60 address it works fine. Am I going mad, or is there something that would cause this behavior? Look at the routing table in the system that you are pinging from and the IP configuration. I'm betting that it has an address in 138.23.76.0/24. And if the system you are pinging from doesn't have an address in that network then I'm betting that the last hop router before the LEAF box has an address in that network. -Tom -- Tom Eastep\ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.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] Weird Proxy Arp Setup
If you haven't read Charles' reply, please read it first. He covers the basics of what you should be looking at on the LEAF router (and reporting to us). I try to go beyond that, without duplicating his effort, in my comemnts interspersed below. At 11:52 AM 7/12/2004 -0700, Ryan Rich wrote: Ok, First I want to thanks everyone for their responses so far! I will stop being ambigious, since it seems to make things more complicated and I think where i work probably has the whole 138.23.0.0/16 block anyways so that secret is already out... My address are on the 138.23.75.0 and 138.23.76.0 subnets. You are correct in all of these guesses (According to the ARIN database). This suggests a different approach to solving your problem: talk to the sysadmin in charge of whatever system is the gateway for these two networks. Ask him or her to set its routing table to make (for example) 138.23.75.254 (the external address of the LEAF router) its default route to 138.23.76.0/24. This might not work ... after all, someone was silly enough to select a set of address ranges that do not combine to a /23 ... but it might be a solution to your problem. I have been trying to narrow down the problem with the machine that was unreachable in the dmz, so I removed the multiple addresses from the eth0 interface on the leaf box and currently only have 1 machine in the dmz. Currently for testing I am using the following setup... LEAF eth0=138.23.75.52 mask 255.255.255.0 LEAF eth1=192.168.1.1 Machine in dmz=138.23.75.60 mask 255.255.255.0 Just to emphasize what you've done: this test setup eliminates all use of the 138.23.76.0/24 network. So *complicated* proxy-arp issues are now out the door. The leaf box is able to ping the machine in the dmz and the machine in the dmz can ping the leaf box. So everything between these two machines seems great. Route shows up for 138.23.75.60 via eth1. Please report this exactly, not via a paraphrase. (That is, quote the complete output of ip route show or netstat -nr.) However, when I try to ping the machine in the dmz from another machine, there is no luck (shorewall has been set to allow pings and there is nothing in the log). Also the machine in the dmz can ping nothing outside of the leaf box. Please describe the failure mode exactly, not with vague phrases like no luck. I am bit confused about you use of the term DMZ here. Usually, it refers to a subset of hosts on a separate *physical* network, for example here on an eth2 interface. But you say your route to it is on eth1, which is usually the internal interface ... the one that handles NAT'ing of a private-address-range LAN and that you say is assigned 192.168.1.1, an address consistent with that custoary use. So, two things come to mind. 1. Does the DMZ host (which you say is 138.23.75.60 mask 255.255.255.0) have a proper routing table? Specifically, does it know that its route to the Internet is 192.168.1.1? Since this eth1 interface does not have a 138.23.75.0/24 address, it cannot proxy-arp the LEAF router's default gateway (which I assume is some 138.23.75.d address ... but maybe next time you better fill in this blank too). 2. Do you have proxy arp enabled properly on the LEAF router? You check this by checking the values of /proc/sys/net/ipv4/conf/eth0/proxy_arp /proc/sys/net/ipv4/conf/eth1/proxy_arp /proc/sys/net/ipv4/conf/all/proxy_arp /proc/sys/net/ipv4/conf/default/proxy_arp (your system may not have the last one) to make sure suitable ones contain 1 values. (I believe a 1 for all or default overrides a 0 for eth0 or eth1.) Another way to test directly for whether proxy arp is working isto use a host on the LEAF router's external network. (If you have access to the gateway host, that would be a good choice.) Run these two commands: ping 138.23.75.52 ping 138.23.75.60 No matter how the pings themselves turn out, now check the arp table on the host you've ping'ed from. How you do this is OS specific; in Linux. you'd cat /proc/net/arp. If both Ip addresses are present and show the same associated MAC address, then proxy arp is working as it should. Now, if I give the same machine in the dmz the address I used for the machine that did work before (138.23.76.112 mask 255.255.255.0) everything works beautifully! The 138.23.76.112 address in the dmz works if the LEAF eth0 interface is assigned an address in the 138.23.75 or the 138.23.76 subnet too, so I guess that is not an issue after all. Just to be clear ... do you mean that in this case, an off-LAN host can ping the on-LAN 138.23.76.112 host and get a response? Are you sure the response is coming from that host (does it come via the LEAF router's MAC address?)? I also can't tell what actual tests your last sentence refers to ... surely you didn't try all possible combinations of addresses. So right now I am baffled. If I plug the machine in the dmz directly into the network
Re: [leaf-user] Arp replacement
Ray Olszewski wrote: No matter how the pings themselves turn out, now check the arp table on the host you've ping'ed from. How you do this is OS specific; in Linux. you'd cat /proc/net/arp. If both Ip addresses are present and show the same associated MAC address, then proxy arp is working as it should. Or using iproute2 (I like sticking to the ip command, and to the man with a hammer...): ip neighbor show -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.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] Arp replacement
At 07:35 PM 7/12/2004 -0500, Charles Steinkuehler wrote: Ray Olszewski wrote: No matter how the pings themselves turn out, now check the arp table on the host you've ping'ed from. How you do this is OS specific; in Linux. you'd cat /proc/net/arp. If both Ip addresses are present and show the same associated MAC address, then proxy arp is working as it should. Or using iproute2 (I like sticking to the ip command, and to the man with a hammer...): ip neighbor show Wimp. I once saw Linus doing a presentation about the early days of Linux. He said something like: Well, at that point we had a kernel, a shell, and a compiler working. And that's all we really needed. Someone asked, What about an editor? He responded, Real men use cat. OK, to be serious ... although iproute2 (ip) is standard on current LEAF systems, it isn't standard on all Linux distros. A stock Debian installation, for example, still doen't include it in the base config (it's an optional package). The only reliable procedure I know of for checking the arp table on *any* Linux system is to cat (or more) the relevant pseudofile directly. He could also use arping, which will return the MAC address as part of the ping response itself. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.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] Bering-uClibc 2.1.x - OpenVPNZ
Hi, Can anyone kindly to send an old version of OpenVPNZ package, as the one on the web seems broken. Many Thanks in advance. Regards, Chris Lee --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.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] Weird Proxy Arp Setup
Ok, I really appreciate the help here, I've tried to modify the setup for now by taking shorewall out of the mix by doing a shorewall stop; shorewall clear and then have everything setup manually. I think I have followed your instructions correctly except for the addresses for the eth1 interface as I noted below with my responses... I can't tell you exactly what given the nearly complete lack of diagnostic information, but I'll try to get you headed in the right direction. First, let's get some details out of the way: - It sounds like you only have an upstream (eth0) and dmz (eth1) interface on your Bering box...is that correct? Correct. - You have two subnets connected to the upstream interface of your firewall: 138.23.75.0/24 and 138.23.76.0/24, correct? Correct. - You want to put externally visible IP's from both subnet ranges on a proxy-arp DMZ connected to eth1 of your firewall, correct? Correct. OK, assuming all of the above is accurate, you need to setup the following: - eth0 should be configured with: * An IP address on both subnets * A local route to each subnet * A default route to your upstream gateway * Proxy-arp enabled - eth1 should be configured with: * An IP address on both subnets (different IP's than used for eth0) * A host route for each public IP to make visible upstream * Proxy-arp enabled I was under the impression that the IP address(es) assigned to the interface connected to the dmz network were irrelevant when using proxy arp after reading the shorewall docs... Please correct me if I am wrong... It will take me a little while to scrape together a couple of extra available IPs from both nets if I really do need them... For now I have just assigned eth1 on the leaf box 192.168.1.1 with a mask of 255.255.255.255 and broadcast of 0.0.0.0. You can verify this setup (and report diagnostics to the list) with the following commands: ip addr list ip route list for i in /proc/sys/net/ipv4/conf/*/proxy_arp ; do echo $i: ; cat $i ; done (started with a shorewall stop ; shorewall clear) begin diagnostics firewall# ip addr list 1: lo: LOOPBACK,UP mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 2: dummy0: BROADCAST,NOARP mtu 1500 qdisc noop link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 3: eth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:10:4b:9e:82:d6 brd ff:ff:ff:ff:ff:ff inet 138.23.75.52/24 brd 138.23.75.255 scope global eth0 inet 138.23.76.127/24 brd 138.23.76.255 scope global eth0:0 4: eth1: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:10:4b:6a:83:ee brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/32 scope global eth1 firewall# ip route list 138.23.76.112 dev eth1 scope link 138.23.75.60 dev eth1 scope link 138.23.75.0/24 dev eth0 proto kernel scope link src 138.23.75.52 138.23.76.0/24 dev eth0 proto kernel scope link src 138.23.76.127 default via 138.23.75.1 dev eth0 firewall# for i in /proc/sys/net/ipv4/conf/*/proxy_arp ; do echo $i: ; cat $i ; done /proc/sys/net/ipv4/conf/all/proxy_arp: 0 /proc/sys/net/ipv4/conf/default/proxy_arp: 0 /proc/sys/net/ipv4/conf/eth0/proxy_arp: 1 /proc/sys/net/ipv4/conf/eth1/proxy_arp: 1 /proc/sys/net/ipv4/conf/lo/proxy_arp: 0 end diagnostics Everything seems to work the same as it did when I set this up through shorewall. All traffic to and from 138.23.76.112 works fine, but 138.23.75.60 is unaccessable except via the leaf box or the 138.23.76.112 machine in the dmz. Also the 138.23.75.60 machine is able to ping both external interfaces on the leaf box, but nothing beyond that. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.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] Weird Proxy Arp Setup
Ryan Rich wrote: Ryan Rich wrote: So right now I am baffled. If I plug the machine in the dmz directly into the network with the 138.23.75.60 address it works fine. Am I going mad, or is there something that would cause this behavior? Look at the routing table in the system that you are pinging from and the IP configuration. I'm betting that it has an address in 138.23.76.0/24. And if the system you are pinging from doesn't have an address in that network then I'm betting that the last hop router before the LEAF box has an address in that network. This is true as to how I tested today, but this machine has been plugged into this same network with that address prior to my leaf experiments and I have been able to access it from my home network without any problem as well. I don't understand your network topology well enough to comment. But I have a very firm grasp of how ARP works. The whole purpose of Proxy ARP is so that a router will respond to ARP who-has requests for IP addresses owned by hosts on the opposite side of the router -- as far as I can tell, you are beating your head against the wall trying to get your router to respond to ARP requests that aren't being sent. If you don't believe me, install tcpdump on the LEAF box and watch the ARP traffic: tcpdump -ni eth0 arp -Tom -- Tom Eastep\ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.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
