What is a WAN <PPP/SLIP> Interface?

Question

My colleague recently pinged our DC and instead of replying from it's static IP it replied from it's WAN Interface. I think it has something to do with the VPN connections we allow which we setup through Routing and Remote Access. The interface also has a DNS entry and it's in the same range as it's static IP.

Any idea's as to what it is, what it does, and why my colleague got a response from it rather than the static IP set?

Solution 1

It sounds like you're saying that it replied from an NDISWANIP interface. That's the virtual interface that the Routing and Remote Access Service (RRAS) uses. You're "seeing" it there because you've got RRAS enabled. It's there to support the function of RRAS, and it will respond to PINGs, etc, because, to the server computer, it's a network interface (albeit virtual). Its IP address is registered under the same name as the server computer itself, so round-robin DNS load balancing will return its IP address, instead of the static IP assigned to the server computer's physical NIC, some fraction of the time.

If you want to prevent the RRAS server from registering the NDISWANIP interface's IP address in DNS, have a look here: http://support.microsoft.com/kb/292822 Generally, I disable the DNS registration for the NDISWANIP interface on domain controller computers that are hosting RRAS.

The answer from Kip about SLIP is right. PPP is used for more than serial-line networking, though. PPP is a generalized protocol that can be used on any media. If you've ever used a DSL line, you've probably used PPP over Ethernet (PPPoE), which is an example of an application of PPP.

Solution 2

That's permitted by the RFCs that define the IP protocol. Actually, to be more specific, it is permitted because it isn't expressly disallowed by RFC 792 (http://www.faqs.org/rfcs/rfc792.html).

Some kernel developers, when writing TCP/IP implementations, have just plain found it easier to write the code that generates ICMP reply packets such that the source address (of the reply packet) is the most convenient IP address laying around (usually the first interface, or the first interface to be configured).

Most people notice this the first time when using traceroute. Traceroute replies tend to come from the "nearest" interface, as one would expect. However, since traceroute is based on ICMP "ttl exceeded" errors, those packets can come from any IP address on the system.

I'm not saying that kernel developers are lazy, I'm saying that this kind of code is non-trivial. Figuring out which interface is "nearest" is actually rather difficult in many TCP/IP implementations because what interface a packet entered the system is not recorded. Carrying that information from cradle to grave just so that traceroute looks pretty is a waste.

Most people are not aware of this because (1) most hosts only have 1 IP address, or (2) many vendors have carefully crafted their TCP/IP implementation to go the extra step of making sure ICMP errors come from the IP address that a human would expect. Cisco was the first to do this and since they are so large anyone that doesn't do this is assumed to have written buggy code. (I worked at a vendor that made a router and, after getting tired of telling customer after customer "it isn't a bug, look at the RFC!" just gave up and implemented it to be "like Cisco" so they didn't have to keep explaining it to customers).

For ping, RFC 792 is pretty clear that the reply should come from the IP address that received the packet. The reason MS might not do that is that you have passed through some kind of NAT, or their alias mechanism is so light weight that the actual IP address the packet was sent to gets thrown away by one layer and by the time it gets to the ICMP (ping) processing there is no other logical thing to do.

If this is causing a problem, ping the other IP address.