XPost: comp.dcom.lans.ethernet
From: gah@ugcs.caltech.edu
james wrote:
Note that this is an IP question, not an ethernet question.
I added comp.protocols.tcp-ip to the list.
< If from within my LAN, I ping my WAN ip, how is the ping packet
< routed to the destination?
Traditionally, which means before NAT, a host accepts packets
to all its addresses. NAT changed the rules.
< Does it go out of the router, to the ISP, then back to the
< router (ping target)?
< Or is the router smart enough to know it is the ping target, so it respond
< to the ping directly without forwarding it to the ISP? If it does this,
< should it also observe the security rules on the WAN side? E.g. if I the WAN
< is setup to ignore pings, then it should ignore this ping.
Note that the results might be different for ICMP (ping), UDP, and TCP.
Independent of NAT, a task may request UDP and TCP connections from
a specific address, or from IADDR_ANY. One might have different
servers for different addresses, for example.
< There are two ocassions when this is an issue:
< (1) when you just set up a web site on the LAN with proper port forwarding
< and you want to verify it is accessible from the outside. If the router does
< not forward the request on to the ISP, then it is not a true test. You may
< be able to view your web site from within the LAN but not from outside.
For port forwarding, which required NAT, it doesn't have to forward
to the ISP, but it does have to process it as though it came in from
the outside. It has to go through the outgoing NAT processing, and
then through the incoming NAT processing. As far as I know, not
all NAT implementations do that. Also, this is where TCP can give
different results.
One that I did once with a NAT implementation was to setup
port forwarding to forward to an outside address. It turns out,
that at least for that specific NAT implementation, that when
it does that it doesn't change the source address. The replies
were sent directly to the originating host, not back through NAT.
That can work for UDP but never for TCP.
< (2) The opposite of (1) -- you just set up a router and you want to make
< sure the router's login page is not accessible from the WAN. I actually did
< this: put the WAN ip in my browser and my router's login page pop up. At
< first I thought I have a security hole, then I realize my router is
< intercepting the request. When I use an http proxy server to test the same
< ip, there is no response, as expected.
It gets more interesting when you add DNS. With NAT, one should have
an internal DNS server to handle internal hosts and supply internal
addresses. An external DNS (which may be implemented through port
forwarding to an internal server), which returns external addresses.
< Strangely, I encounted two different behavior from two different routers
< (both the same brand, though different model). My router would short-circuit
< the request and not forward it to the ISP. My friend's router would drop the
< request entirely -- so that if he has a web server at, say 123.4.56.789:300,
< then typing this IP into the web browser from within the LAN produces an
< error saying no such address. But using another ISP to test reveal that
< there is indeed a web server at that address.
Yes, I believe that NAT can implement it either way.
< One way I can truely simulate a ping (or http request) from the outside is
< to use an http proxy. The other way is of course to use a different ISP to
< send the request.
Yes, both of those work.
-- glen
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
