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
>> 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
> 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)