RRAS Internal interface using APIPA address, ignoring both DHCP an

[Jacques Assert]

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!

[Bill Grant]

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@nospam.nospam> wrote in message
news:B3266A66-CE6E-43A3-93C0-42F851EA82E9@microsoft.com...
>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!

[Jacques Assert]

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@nospam.nospam> wrote in message
> news:B3266A66-CE6E-43A3-93C0-42F851EA82E9@microsoft.com...
>> 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!
>

[Bill Grant]

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@nospam.nospam> wrote in message
news:uJq9oEAaIHA.536@TK2MSFTNGP06.phx.gbl...
> 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@nospam.nospam> wrote in message
>> news:B3266A66-CE6E-43A3-93C0-42F851EA82E9@microsoft.com...
>>> 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!
>>

[Jacques Assert]

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.

JA

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@nospam.nospam> wrote in message
> news:uJq9oEAaIHA.536@TK2MSFTNGP06.phx.gbl...
>> 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@nospam.nospam> wrote in message
>>> news:B3266A66-CE6E-43A3-93C0-42F851EA82E9@microsoft.com...
>>>> 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!
>>>
>

[Jacques Assert]

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" <jackassert@nospam.nospam> wrote in message
> news:uJq9oEAaIHA.536@TK2MSFTNGP06.phx.gbl...
>> 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@nospam.nospam> wrote in message
>>> news:B3266A66-CE6E-43A3-93C0-42F851EA82E9@microsoft.com...
>>>> 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!
>>>
>