What happens when I ping my own WAN IP from LAN side?

If from within my LAN, I ping my WAN ip, how is the ping packet routed to the destination?

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.

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.

(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.

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.

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.

Reply to
james
Loading thread data ...

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

Reply to
glen herrmannsfeldt

What does TRACERT show you? That ``tool'' uses ICMP echos (ping) By the way, what does this have to do with Ethernet? More appropriate is

comp.protocols.tcp-ip TCP and IP network protocols.

No

Bingo

That depends - if it's a firewall rule to ignore ICMP echo, then it could be interface dependent. If it's a kernel parameter to ignore ICMP echo, then it would be on all interfaces. Recall it's not the interface that is answering the ping, but the network stack part of the operating system. Think of it by comparing a firewall rule that blocks access at an interface, verses not running the server at all. With a firewall, the server is accessible from someplace - if the server isn't running...

Please remember that ping (ICMP Echo) is not TCP/IP. Different rules may apply.

You must also realize that your ISP doesn't have a single computer where all packets are routed/filtered/etc. Blocking may occur at the perimeter as well as the router you are connected to. Did you check with the ISP to see that you are permitted to run a server on your IP?

Yeah, if you don't know what you are doing, you are likely to have a problem of some kind. What's new about that?

Not configured the same way. Either router may be configured either way - default modes are not the only way a router can operate.

It's rather old, but still quite useful:

1180 TCP/IP tutorial. T.J. Socolofsky, C.J. Kale. January 1991. (Format: TXT=65494 bytes) (Status: INFORMATIONAL)

RFC1180 can be found using your favorite search engine. If you want to get into technical details, see RFC1122, RFC1123 (Requirements for Internet Hosts) and RFC1812 (Requirements for IPv4 Routers). RFC2827 and RFC3704 discuss filtering rules that may be of interest.

Old guy

Reply to
Moe Trin

Hello,

glen herrmannsfeldt a écrit :

As it has nothing to do with ethernet, I set a follow-up to comp.protocols.tcp-ip.

This behaviour is referred to as "weak host model". What does it have to do with NAT ?

Reply to
Pascal Hambourg

I don't know why there would ever be an exception to that, and I don't understand why a NAT would change anything?

If you ping the WAN side IP address of your local router, from behind a NAT, the request should go through the NAT and to only as far as this router, no? And the echo reply message from the WAN router should be addressed to the public IP address that the NAT applied to your host, go through the NAT, and back to your host.

My assumption is that you have WAN--router--NAT--host, where what I'm calling "router" is often referred to as modem.

I don't understand under what circumstances the echo request would ever go all the way to the ISP? Maybe my assumption of the setup is wrong.

Bert

Reply to
Albert Manfredi

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.