Well, I was about to give up on this whole thing and try a different approach... I came in this morning ready to give this one last shot and when I booted up the leaf machine this morning everything worked!!! I don't know if this was an ARP Cache issue like Tom mentions in the Shorewall docs (if it was, then they have a REALLY long timeout here) or network gremlins?!?! I was in fact going to try the arping technique that Tom mentions on the shorewall page back on the first day I was working on this, but figured by the time I got my env setup so I could compile with uClibC that it would have expired from the cache anyhow. I really wish I knew what happened that caused this for sure for future reference, as this was one of my more frustrating experiences.
Many thanks to everyone, especially Charles, Ray and Tom. Is there a place to give donations to the leaf project? I will at least try to contribute an arping.lrp package in case that was my problem so that it may help others. By the way, the private ip address does work as the address for eth1, but per your advice I will change this to the same addresses I used for the eth0 interface if this is a more commonly accepted practice. Thanks Again, Ryan Rich > Ryan Rich wrote: > >> <<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 > > Why are you assigning a private IP to your DMZ interface? As mentioned, > you should assign unique public IPs from both networks to your DMZ > interface. > > Note that this may not absolutely be required (typically you can > "re-use" the IP's assigned to the upstream interface), but it makes > things a lot less confusing. > > I'm also unsure if proxy-arp will work at all without an appropriate IP > assigned to the NIC (I've never tested anything like this). > >> 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 > > This looks generally OK. > >> 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 > > This looks correct. > >> <<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. > > Assign real IP's to the DMZ interface on your firewall and see what > happens. I suspect you've got things *REALLY* confused by using the > private IP. > > We also need to see the network setup on your DMZ system(s), both the IP > address(es) and a dump of the route table. Other info that might be of > some use: > > - A dump of the arp cache from the firewall and the DMZ system(s) after > trying to ping outside the DMZ would be > > - A tcpdump of traffic on the DMZ interface while running the above ping > tests. > > -- > Charles Steinkuehler > [EMAIL PROTECTED] > -- Ryan Rich Sun Certified Programmer for Java 2 Platform Oracle Developer http://www.richservices.com/ ------------------------------------------------------- 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
