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.
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. 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. Have you tried binding
other services to that IP and accessing them?