|
||||||||
On Wed, 06 Apr 2005 20:37:39 -0400, Chris Buechler wrote: > On Apr 5, 2005 3:34 AM, Jesse D. Guardiani <jesse at wingnet dot net> wrote: >> >> 1.) A ping from the m0n0wall webgui to 192.168.90.3 seems to work, but >> please examine the below tcpdump output, taken from 192.168.90.3 >> during the ping test, and tell me if anything looks incorrect: >> >> 03:04:11.410313 IP 192.168.89.1 > 192.168.90.3: icmp 64: echo request >> seq 0 >> 03:04:11.475002 IP 192.168.90.3 > 192.168.89.1: icmp 64: echo reply seq >> 0 >> 03:04:11.416746 IP 192.168.89.1 > 192.168.90.3: icmp 64: echo request >> seq 0 >> 03:04:11.416816 IP 192.168.90.3 > 192.168.89.1: icmp 64: echo reply seq >> 0 > > I just tried this, and got the same result from either m0n0wall itself > or directly from a client machine. Tried what? Please be more specific. > Assuming they're all on the same subnet, the adding a static route to > the host working makes no sense. If m0n0wall has a static route to > something out the same interface it came in on, it'll bounce back an > ICMP redirect, and the host machine, if it accepts ICMP redirects > (pretty much every OS does by default), will communicate without even > touching m0n0wall on subsequent traffic. That's just it. I haven't seen any ICMP redirects from m0n0wall for this. I have a production m0n0wall machine doing a static route just fine, but the static route gateway points to a cisco router. I'm just trying to figure out why it doesn't work when I point the static route gateway to a Linux machine. > tcpdump and routing tables > of the sending host verified this worked as it should. Snippet of > 'route print' from a Windows host. 10.0.10.2 is the IP alias I added > to one of my hosts, 10.0.40.3 is the machine the route pointed to (the > "real" IP of the machine with the alias), 10.0.40.21 is the IP on the > interface of the Windows system. > > Network Destination Netmask Gateway Interface Metric > 10.0.10.2 255.255.255.255 10.0.40.3 10.0.40.21 1 > > I could ping the machine as well as hit HTTP and SSH on it. Didn't > try any UDP services, though I'd imagine those would work as well. > > Since everything seems to work fine for me doing this, I'd lean > towards Asterisk as the source of the problem. Forget asterisk. It has nothing to do with this issue. This is a general routing issue. I'm not even attempting to bind asterisk to 90.3. It's a different daemon I'm attempting to bind to 90.3, and I've tried all sorts of programs, like `ping -I 192.168.90.3 192.168.89.1` with the same results. The fact that this box is named asterisk.guardiani.us and that it happens to run asterisk is merely a coincidence. > Have you tried binding > other services to that IP and accessing them? Yes. See above. -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net |