The subject line is truncated, but this problem ignores both DHCP and
static addresses. In either case, the Internal adapter has a APIPA
address. My guess is that there is bit rot in some RRAS related
component, as the system has been running for a couple years.
A reinstall of the RRAS role does not change the problem, and I'm trying
to avoid a reinstall of the machine since it's not my goal in life.
James
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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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" <(E-Mail Removed)> wrote in message
>>> news:B3266A66-CE6E-43A3-93C0-(E-Mail Removed)...
>>>> 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
>>>> installed.
>>>>
>>>> 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?
>>>>
>>>> Thanks!
>>>
>
|