First, I'm moving the public end of this discussion from leaf-devel to
leaf-user. That's the list where troubleshooting requests belong (and I
apologize to the LEAF developers for missing this the first time around).
Second, some of the details in your reply to me suggest that your problem is
not in iptables but in more general configuration errors. This means we need
a standard report about the basics of your setup, namely
what LEAF distribution, what floppy or CD image, what kernel
output of "ip link show"
output of "netstat -nr"
either tell us that the LEAF router *itself* can ping the
test IP addresses you are using on the LAN and
the DMZ, or report the errors any failures generate
Third, with respect to all of the tests that you report below, do the LEAF
router's logs list anything about them? If so, what?
At 07:24 AM 2/26/02 -0600, bishoju wrote:
><snip>
>(But please do confirm this -- the script used eth1 and eth2, but not eth0
>.. an extremely unusual setup.)
></snip>
>
>Yes that is correct. In the script if I change EXT_IFACE to eth0 nothing
>works. However, my last provider went out of business and they used static
>IPs, PPPOE is new to me. I 'm not sure if the rules should be broken out
>somehow into ppp0 and eth0 separately and would need guidance on how that
>should be done. If I do need to somehow specify eth0 then I don't know how
>I'm getting a connection now.
Oh, OK, this is a PPPoE setup. I didn't realize that. What you have is
probably right for it. I was assuming a dialup ppp0 rather than PPPoE.
><snip>
>What services did you try, from where, and with what specific results?
></snip>
>
>Just like a typical end user. Here's a few sample listings.
>All of this is from 192.168.1.7
And this is a workstation on the LAN, right?
>jud@tux:~> ping -c 1 192.168.2.2
>PING 192.168.2.2 (192.168.2.2) from 192.168.1.7 : 56(84) bytes of data.
>>From 192.168.1.254: icmp_seq=1 Destination Host Unreachable
>>From 192.168.1.254 icmp_seq=1 Destination Host Unreachable
>
>--- 192.168.2.2 ping statistics ---
>1 packets transmitted, 0 received, +2 errors, 100% loss, time 0ms
>
>Do need an ip route add ???
Maybe. That's certainly what the ping-failure message suggests, rather than
an iptables problem. The destination here is your DMZ host, and it is
certainly easy to misconfigure LEAF in DMZ settings. You'd do better to get
the LEAF setup scripts working right than just throw in an "ip route add
..." line somewhere.
>jud@tux:~> ping -c 1 66.157.130.163
>PING 66.157.130.163 (66.157.130.163) from 192.168.1.7 : 56(84) bytes of data.
>64 bytes from 66.157.130.163: icmp_seq=1 ttl=255 time=504 usec
>
>--- 66.157.130.163 ping statistics ---
>1 packets transmitted, 1 received, 0% loss, time 0ms
>rtt min/avg/max/mdev = 0.504/0.504/0.504/0.000 ms
This says you *can* ping the Internet from the LAN. (I'm assuming
66.157.130.163 is a remote host, and not the router's external-interface
address. But I may be mistaken in this; I find right now that I cannot ping
66.157.130.163 from here; I get no responses.)
>jud@tux:~> ssh -p 2222 66.157.130.163
>jud@tux:~> ssh -v -p 2222 66.157.130.163
>OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
>debug1: Reading configuration data /etc/ssh/ssh_config
>debug1: Applying options for *
>debug1: Seeding random number generator
>debug1: Rhosts Authentication disabled, originating port will not be trusted.
>debug1: restore_uid
>debug1: ssh_connect: getuid 500 geteuid 0 anon 1
>debug1: Connecting to 66.157.130.163 [66.157.130.163] port 2222.
>debug1: temporarily_use_uid: 500/100 (e=0)
>debug1: restore_uid
>debug1: temporarily_use_uid: 500/100 (e=0)
>
>Then it just sits.
Sits for how long? If you give it less than 3 minutes, you might be
experiencing a DNS problem on the destination host (66.157.130.163). Is that
a host you have control over (or access to)? What OS does it run? Why the
non-standard port?
>jud@tux:~> ssh -v 192.168.2.2
>OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
>debug1: Reading configuration data /etc/ssh/ssh_config
>debug1: Applying options for *
>debug1: Seeding random number generator
>debug1: Rhosts Authentication disabled, originating port will not be trusted.
>debug1: restore_uid
>debug1: ssh_connect: getuid 500 geteuid 0 anon 1
>debug1: Connecting to 192.168.2.2 [192.168.2.2] port 22.
>debug1: temporarily_use_uid: 500/100 (e=0)
>debug1: restore_uid
>debug1: temporarily_use_uid: 500/100 (e=0)
>debug1: connect: No route to host
>debug1: restore_uid
>debug1: Trying again...
>debug1: Connecting to 192.168.2.2 [192.168.2.2] port 22.
>debug1: temporarily_use_uid: 500/100 (e=0)
>debug1: restore_uid
>debug1: temporarily_use_uid: 500/100 (e=0)
>debug1: connect: No route to host
>debug1: restore_uid
>debug1: Trying again...
>debug1: Connecting to 192.168.2.2 [192.168.2.2] port 22.
>debug1: temporarily_use_uid: 500/100 (e=0)
>debug1: restore_uid
>debug1: temporarily_use_uid: 500/100 (e=0)
>debug1: connect: No route to host
>debug1: restore_uid
>debug1: Trying again...
>debug1: Connecting to 192.168.2.2 [192.168.2.2] port 22.
>debug1: temporarily_use_uid: 500/100 (e=0)
>debug1: restore_uid
>debug1: temporarily_use_uid: 500/100 (e=0)
>debug1: connect: No route to host
>debug1: restore_uid
>Secure connection to 192.168.2.2 refused.
>
>SSH is the interesting one to me. I copied my identity.pub and id_dsa.pub
>over as authorized_keys and authorized_keys2.
But what matters here is this line (repeated in a couple of places) --
>debug1: connect: No route to host
-- which tells us that you have a routing problem, not an ssh problem. In
this respect, this connection attempt is clearly different from the "just
hangs" you expereince when trying to connect to 66.157.130.163.
>When I try to surf to http://192.168.2.2 I get connection refused.
>When I try to surf to http://66.157.130.163 I get operation timed out.
Can I assume that there are http servers running on both target hosts? And
that you are still connecting from 192.168.1.7? What browser are you using
(knowing that helps when interpreting error messages)?
-IF- these results are caused by firewalling problems, the first is
consistent with the "no route to host" result you get elsewhere. The second
suggests that packets can go out OK, but that return packets are firewalled.
But that's only a possibility; there are other explanations too, and without
knowing the basics of your setup or anytbing about what 66.157.130.163 is,
we can't rule them out.
>When I ping from 192.68.2.2 to 192.168.1.7 I also get an answer. As well as I
>hang trying ssh from 192.168.2.2
>
Just to be clear -- are you saying here that you *can* ping from 192.68.2.2
(the SMZ) to 192.168.1.7 (the LAN), but you *cannot* ssh from 192.68.2.2 to
192.168.1.7? If so ... here again the 3-minute rule applies to ssh. And you
need to explore whether the LAN host, 192.168.1.7, has a way to do a reverse
lookup on the DMZ host, 192.168.2.2.
More fundamentally, even if it does work this way, this is NOT a
configuration error. Hosts on the DMZ are supposed to be unable to initiate
connections to the LAN. Otherwise, it isn't a DMZ. Ideally, even the pings
would fail.
>Jud Bishop
>
>
--
------------------------------------"Never tell me the odds!"---
Ray Olszewski -- Han Solo
Palo Alto, CA [EMAIL PROTECTED]
----------------------------------------------------------------
_______________________________________________
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
