|
||||||||
On Sat, 09 Apr 2005 11:49:45 -0400, Jesse Guardiani wrote: > On Thu, 07 Apr 2005 17:28:52 -0400, Chris Buechler wrote: > >> On Apr 7, 2005 5:01 PM, Jesse Guardiani <jesse at wingnet dot net> wrote: >>> 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. >>> >> >> m0n0wall (LAN) is 10.0.40.1 (/24) >> server at 10.0.40.3 >> PC at 10.0.40.21 >> >> Added alias ('ifconfig em0 inet 10.0.10.2 netmask 255.255.255.255 >> alias' on FreeBSD) on the server in question. >> >> Added static route to m0n0wall, on LAN interface, pointing >> 10.0.10.2/32 to 10.0.40.3. >> >> With Ethereal going, tried to ping 10.0.10.2 from 10.0.40.21. First >> ping went through, routed by m0n0wall, ICMP redirect was sent from >> m0n0wall, subsequent pings went through without touching m0n0wall. I >> could hit http://10.0.10.2, ssh to 10.0.10.2, etc. Everything I tried >> worked fine. >> >> One thing I just thought of was that these services aren't strictly >> bound to the 10.0.10.2 IP, they're bound to all IP's. Regardless, >> that shouldn't matter. >> >> >>> >>> > 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. >>> >> >> Yeah I didn't see any ICMP redirects either in your tcpdumps. With >> that static route added, go to exec.php and run a 'route print >> 1.2.3.4/32' (replaced with the IP of the route) and see what comes >> back. > > route print doesn't seem to exist. Is this what you mean? > > $ route get 192.168.89.52 > route to: asterisk > destination: asterisk > interface: fxp2 > flags: <UP,HOST,DONE,LLINFO,WASCLONED> > recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire > 0 0 0 0 0 0 1500 > -289 > > $ route get 192.168.90.0/32 > route to: 192.168.90.0 > destination: 192.168.90.0 > mask: 255.255.255.255 > gateway: asterisk > interface: fxp2 > flags: <UP,GATEWAY,DONE,STATIC> > recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire > 0 0 0 0 0 0 1500 > 0 > > >> You're using 1.2b7, I reverted my production box back to b3. One >> other difference is you're using OPT, I'm using LAN. I'm curious if >> you try a pre-5.3 version if it works as intended. I'll see if I can >> try a b7 test box, and try an OPT interface. > > I just tried 1.2b3 with the same result. Maybe it's the OPT interface > thing. I can't really test on the LAN interface though. Can you? Captive Portal!!! I disabled my captive portal on the wlan interface and now my static route ICMP redirects come through!!! Is this a bug? Can it be changed/fixed? Bare minimum, it should be an FAQ! Thanks for the help Chris!! I can't tell you how useful it is to have someone to help me confirm/deny my fringe case problems! Much appreciated! -- 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 |