Re: RRAS Internal interface using APIPA address, ignoring both DHCP an

I have tried using both a static pool and the DHCP with no change. In both cases, an APIPA address is used on the Internal adapter instead. Based on my previous experience, and your confirmation, I assume that something basic is screwed up.

I guess my real question is can this be resolved without reinstalling the system. I guess I could burn an incident for this type of once-in-a-hopefully-lifetime bug.


Bill Grant wrote:
To the best of my knowledge the answer to all three questions is NO.

Have you tried using a static pool of addresses rather than DHCP? Does that work?

"Jacques Assert" <jackassert@xxxxxxxxxxxxx> wrote in message news:uJq9oEAaIHA.536@xxxxxxxxxxxxxxxxxxxxxxx
I've used RRAS+DC since the NT days, so I've some familiarity at this point. There was one refcount problem with NAT in W2K SP3 that I helped to debug. It had the effect of WinNUKE in that it would BSOD a fresh install if you sent it the right traffic.

Typically, the 'Internal' interface acquires an IP from the local DHCP server, as do the RAS endpoints if enabled.

What I have seen in W2K is that the 'Internal' interface is unable to acquire a DHCP address if any physical NIC is disconnected. This can be confusing since the unused NIC can be disabled and use a static IP.

However, I have *never* seen the 'Internal' interface use an APIPA addess (169.254.x.x). Reinstalling RRAS does not affect this behaviour, and I can not set it manually. Further, since this IP is used as an endpoint, it can get sent through a VPN as the source IP and traffic is unable to route back properly.

Q: How can I 'reset' enough of the system to restore the normal Internal interface behaviour and ditch the APIPA (169.254.x.x) address?

Q: How can I enable more detailed debugging to determine which piece is misconfigured/broken? Is there a debug RRAS available outside of MS PSS?

Q: Is it possible to manually/statically configure the Internal adapter?

Bill Grant wrote:
First up two warnings. Running RRAS on a DC is a bad idea and is not recommended (except with SBS which is designed to run that way). It can cause all sorts of problems. I would never use a DC as a remote access server. Secondly,there are known problems running RRAS/NAT on Server 2003 SP2.

Any interface will acquire an APIPA address if it is set to obtain its IP automatically but it cannot find a DHCP server or other allocator softwware (such as RRAS or ICS). Why this particular machine can't find a DHCP server or use the pool is the odd bit if another machine can do it. The only problem I have struck is that the DD interface can't get its IP address from the pool. If it can't find the DHCP server you can give it an IP manually. But you can't do that for the internal interface.

"Jacques Assert" <jackassert@xxxxxxxxxxxxx> wrote in message news:B3266A66-CE6E-43A3-93C0-42F851EA82E9@xxxxxxxxxxxxxxxx
I have a couple of multihomed W2K3+SP2 systems with RRAS (running DOD VPNs
and NAT, with public Internet NIC and private Local Area Connection NIC).
Normally, the Internal interface acquires an IP from DHCP or from the static
address pool, chosen on the IP tab.

On one machine, whether DHCP or static address pool is specified, the
Internal interface always acquires an APIPA addess (169.254.x.x). This raises
havoc with subsequent attempts to establish DOD VPN connections.

I have tried removing and adding the RRAS role without effect.

Note that DHCP runs on the same machine, as does AD, DNS and WINS. Each is
an 'all-in-one' DC acting as a file/print server. No non-MS software is

Q: How can I force the Internal interface to use the setting (DHCP or
static) specified on the IP tab?

Q: How can I reset all of RRAS back to defaults, if removing and adding the
role is not sufficient?

Q: (Extra points) What could cause this APIPA use in the first place?