At 02:00 PM 12/12/02 -0800, Joshua Klein wrote:
Sure thing. But this does seem like a good place to remind you, gently, that LEAF includes FAQs and other materials on its Web site, and that consulting them can be worthwhile when trying to track down problems. And the "SR FAQ", mentioned at the bottom of this and every list message, is especially important for newcomers to read, since it tells you, in general terms, what information you need to supply to get good troubleshooting help.This is my first time on this list, so please be gentle. :)
After reading all the docs, previewing the logs, and lurking on this list forIdentified how? "sendto: Operation not permitted" most often signals a problem with the applicable firewall (ipchains, for Bering) ruleset (see the LEAF FAQs for more detail on interpreting ping failures, or consult the Shorewall docs to see what you might be doing wrong), not with routing itself.
a while I finally decided to try Bering. My goal is to get the
three-interfaces setup on Shorewall along with the pptp server to allow
access to the DMZ from both the Loc and Net zones. Leaving aside pptp for
now, I've managed to get Bering working with my three NICs, dispensing IPs on
eth1 (loc) and eth2 (dmz) w/ dhcp, and picking up a dynamic ip with pump on
eth0 (net).
But that's as far as I've got. So far I can't ping out from the Bering machine
with shorewall started, getting this error:
# ping mit.edu
PING mit.edu (18.7.21.70): 56 data bytes
ping: sendto: Operation not permitted
which I've identified as most likely being routing related.
This probably means that ping responses from the Bering box are blocked by a firewall rule. The next comment reinforces this interpretation.Similarly, I can't ping machines on the loc or dmz subnets, i.e.:# ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 data bytes ping: sendto: Operation not permitted Finally, I can't ping the bering box from either the dmz or loc subnets - attempts to do so just time out.
This is a bad test to start with. You need to find an IP address, not an FQN, that you know responds to pings. For example:When I try these tests with shorewall turned off I can ping the machines on the loc and dmz networks from the bering box, and ping the bering box from said networks, but can't ping out to the Net at large attempts to do so result in: # ping mit.edu ping: unknown host mit.edu
waverly:/home/autovcr# ping mit.edu
PING mit.edu (18.7.21.69): 56 data bytes
64 bytes from 18.7.21.69: icmp_seq=0 ttl=238 time=90.2 ms
64 bytes from 18.7.21.69: icmp_seq=1 ttl=238 time=89.5 ms
64 bytes from 18.7.21.69: icmp_seq=2 ttl=238 time=89.7 ms
--- mit.edu ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 89.5/89.8/90.2 ms
OK. So now *you* try to ping 18.7.21.69, NOT mit.edu . If it works, then you have a DNS problem to troubleshoot. If it doesn't, you have a connectivity problem that the nature of the ping failure will tell you (or at least us, if you post a follow up) a lot about.
How is this different from the prior test? (I see the result is different, but how did the attempt differ?)Trying to ping the Net at large from the bering box gives me this error: # ping mit.edu ping: mit.edu: Host name lookup failure
When I ping the bering box from the Net I get zero results - it just timesStart with the info from the SR FAQ and the ping-related LEAF FAQs. Also see if Tom posts some suggestions specific to Shorewall debugging.
out.
Most frustratingly, no messages appear in the logs on the Bering machine when
I try any of the above. I can see that DNS resolution only occurs when
shorewall is up and that shorewall is blocking ping probes, but can't
pinpoint where that problem stems from.
My main concern is that I would like to be able to debug this myself and don't
know where to start.
If Tom does not suggest something involving a Shorewall config file, then the place to look is in the actual iptables rules, which you display (the relevant part, at least) with "iptables -nvL". See what rules are blocking the pings (or connections to port 53/udp for any DNS-related problems), and backtrack to the Shorewall config element that creates those rules.My first instinct is to reach for tcpdump, but it's not available on Bering. Given that I copied the three-interfaces file set for shorewall and otherwise followed the Installation guide more or less exactly I'd rather not just dump all my .conf files on this list - but can anyone give me any advice on where to start debugging this otherwise?
If you post a followup, please be sure to include the basic info asked for in the SR FAQ. It saves everybody time by answering a jillion little, pesky questions, about your setup.There are only two suspicious things I can see with the LRP load sequence: 1) when booting, shorewall gives me this error: .: Can't open /etc/shorewall/common.def 2) ip addr show lists the first interface as lo, the third, fourth, and five interface as eth 0, eth1, and eth 2 respectively, but the second interface is listed as dummy0, with no inet or brd addresses. What does this mean? Thanks for any and all help, Josh
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA [EMAIL PROTECTED]
-------------------------------------------------------------------------------
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
------------------------------------------------------------------------
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
