Post by thread:[OT:] Can't see internal server from inside via ex

source= http://www.piclist.com/piclist/2003/10/16/191310a.txt? > Can you go from the 192.168.1.6 PC, > through a web based proxy such as > http://www.proxyone.com/ to go back > to the massmind or 66.13.172.18 > address? Yes, but that doesn't explain why I can't go from 192.168.1.6 to 66.13.172.18 directly when anyone else outside the local network can. --- James Newton: PICList.com webmaster, former Admin #3 spam_OUTjamesnewtonTakeThisOuTpiclist.com 1-619-652-0593 phone http://www.piclist.com/member/JMN-EFP-786 PIC/PICList FAQ: http://www.piclist.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

source= http://www.piclist.com/piclist/2003/10/16/192550a.txt? > Could you draw a simple picture with your networks > and those router interfaces ? 192.168.0.1 to 192.168.0.15 are all plugged into a hub that is connected to the router. The WAN side of the router goes to a DSL modem and out to the internet as 66.13.172.18 Can't get any simpler. I didn't enter those in the routing table... the router came up that way... Also the old router, which did work, had the same entries. --- James Newton: PICList.com webmaster, former Admin #3 .....jamesnewtonKILLspam@spam@piclist.com 1-619-652-0593 phone http://www.piclist.com/member/JMN-EFP-786 PIC/PICList FAQ: http://www.piclist.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

James, Do you have another machine with a packet-sniffer in it?? I think what you're going to find is that your machine that can't talk to the 66.x.x.x network machine never ARP's for it, it just forwards packets destined for that machine to its default router because it's outide of it's network range, as defined by its IP address and it's network mask. You should see an ARP "whohas" 66.13.172.18 on the hub as the very first thing that machine does to try to find the other machine. Since you're plugged into a hub, the 66.x.x.x machine should see this ARP broadcast and reply, thus bypassing the router. But if that handshake isn't occurring, then the internal 192.168.x.x machine is having to forward all packets for other hosts to the router's internal address, and then the router is having a hard time figuring out that the 66.x.x.x address is actually on its internal interfce. I missed it in the reply chain, but I'm assuming this is a NAT setup to get to that machine? Anyway, Ethereal or another packet sniffer will quickly tell the story.... On Thu, Oct 16, 2003 at 08:23:45PM -0700, James Newton, webhost wrote: {Quote hidden}> source= http://www.piclist.com/piclist/2003/10/16/192550a.txt? > > > Could you draw a simple picture with your networks > > and those router interfaces ? > > 192.168.0.1 to 192.168.0.15 are all plugged into a hub that is connected to > the router. The WAN side of the router goes to a DSL modem and out to the > internet as 66.13.172.18 > > Can't get any simpler. > > I didn't enter those in the routing table... the router came up that way... > Also the old router, which did work, had the same entries. > > --- > James Newton: PICList.com webmaster, former Admin #3 > jamesnewtonKILLspampiclist.com 1-619-652-0593 phone > http://www.piclist.com/member/JMN-EFP-786 > PIC/PICList FAQ: http://www.piclist.com > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. -- Nate Duehr <.....nateKILLspam.....natetech.com> -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

On Thu, 16 Oct 2003 20:18:45 -0700, "James Newton, webhost" <jamesnewtonspam_OUTPICLIST.COM> wrote: >Yes, but that doesn't explain why I can't go from 192.168.1.6 to >66.13.172.18 directly when anyone else outside the local network can. Lots of NAT boxes won't let you back in the WAN interface from the LAN side. The one currently in use here (a Zyxel) behaves that way. To test web server URLs, I put an entry for the server in the hosts file pointing to the RFC1918 LAN address of the server. There are fairly good technical reasons for not permitting an outgoing session that connects to an incoming session. mdr -- The hits just keep on coming for poor "Nadine". See the sad tale of email lists gone horribly wrong at <http://www.honet.com/Nadine/> F - IW AA #2157 GEVNP . -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email @spam@listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

> On Thu, 16 Oct 2003 20:18:45 -0700, "James Newton, webhost" > <KILLspamjamesnewtonKILLspamPICLIST.COM> wrote: > > >Yes, but that doesn't explain why I can't go from 192.168.1.6 to > >66.13.172.18 directly when anyone else outside the local network can. > > Lots of NAT boxes won't let you back in the WAN interface from the LAN > side. The one currently in use here (a Zyxel) behaves that way. To test > web server URLs, I put an entry for the server in the hosts file pointing > to the RFC1918 LAN address of the server. > > There are fairly good technical reasons for not permitting an outgoing > session that connects to an incoming session. FWIW some DO do this sort of thing. The feature is usually called "internal loopback". My DLink DI604 has this feature. I can't really think of a security reason for NOT allowing this sort of thing. TTYL -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email RemoveMElistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

> Yes, but that doesn't explain why I can't go from 192.168.1.6 to > 66.13.172.18 directly when anyone else outside the local network can. There is no route between those subnets. The router knows how to send from inside to outside and from outside to inside. It does not know how to send from inside to outside to inside (without transiting another host or router). Peter -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestspamBeGonemitvma.mit.edu