|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: [PLUG] Slow access to internet... sometimes
|
> > > Assuming what I wrote above is true, when you connect from the
> > > workstation to the server's public IP address, what address does the
> > > server see the workstation as coming from? Are you sure you have any
> > > connectivity at all -- are you able to ping the server's public address
> > > from your workstation?
> >
> > The server sees the address of the client conencting 10.0.5.19 from
>
> Actually on further inspection, im wrong.... If i connect to 10.0.5.100 then
> the 10.0.5.19 shows up, but if i connect to geiseri.myip.org then the WAN
> address shows up in the http logs...
That makes much more sense; I was struggling to explain how you had any
connectivity at all between the workstation and server if when you
connected to geiseri.myip.org, the server was seeing you come from the
internal address. To understand the problems with that scenario, imagine
the following:
- Your workstation, 10.0.5.19, presumably has a local connected
route to your internal subnet, and a default route pointing to
the netgear device.
- When it attempts to send a packet to 66.92.236.77 (the IP address
that geiseri.myip.org currently resolves to), as it has a no more
specific route, it would use it's default gateway and forward the
packet to the netgear device.
- The netgear device is configured to statically NAT 66.92.236.77
to 10.0.5.100, and would perform this translation before
forwarding the packet to the server. If while performing this
translation it did not also modify the source address of the
workstation:
- The server would see an inbound packet with a source address of
10.0.5.19. When responding to the request, it would therefore send
the response to 10.0.5.19, and because it has a locally connected
route for your internal subnet, the return packet would not pass
through the netgear device.
- When the workstation receives the response from the server, it
would have a source address of 10.0.5.100, which wouldn't match
up with the address 66.92.236.77 it was attempting to contact,
and the response packet from the server would be discarded.
If instead the netgear device NAT'd the source address of the workstation to
another address that the server wouldn't have a locally connected route for
and would therefore need to forward the response packet back through it's
default gateway, the netgear would then have an opportunity to (un)NAT the
response packet before forwarding it to the workstation.
I hope I explained that clearly enough. If not, please let me know.
> Since when a client from the WAN connects the correct address appears in
> the logs, that is starting to make me belive there is a bug in their
> software.... Could this be the case?
No, it is not a bug that when the workstation on your local subnet connects
to the external address of the server it is NAT'd to an external address,
and as far as I can tell based on the information you've provided, you do
indeed have routing on your network configured correctly. That being said,
the fact that you have such poor performance in this scenario does indeed
sound like a bug, or at the very least a performance limitation of the
netgear. You may want to see if a newer firmware is available, or perhaps
give the manufacturer's support number a call.
Other possible workarounds include replacing the netgear device with a low
end Linux box, or simply reaching the server from your workstation using
it's internal address :-)
HTH,
-mct
_________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.netisland.net/mailman/listinfo/plug-announce
General Discussion -- http://lists.netisland.net/mailman/listinfo/plug
|
|