06-27-2011 10:04 PM
I have an ASA 5505 with software version 8.2(1). It is making DHCP requests for IPSec clients that connect to the ASA. The DHCP requests packets the ASA makes have an extra '00' appended to the hostname field, and the length field is the size of the hostname + 1.
The DHCP server is Microsoft Server 2003 and this causes the hostname to be registered with an unknown character which appears as []hostname. Then when server 2003 tries to update the DNS record, it fails because of the invalid character in the hostname.
Is there anyway to have the ASA have the correct length for the hostname field in the DHCP packet, or a workaround that will solve this problem?
Solved! Go to Solution.
06-29-2011 06:36 AM
Hi Mark,
This is exactly the issue described in , here is a copy of the bug release notes:
Symptom:
When VPN Clients connect to the ASA the ASA inserts an extra character or carriage return in the DHCP scope which causes the users' application to display dhcp information on two lines as opposed to one; the extra character causes a line feed on address resolution and automated tools can't handle the result.
This is also noticed as an extra symbol that looks like a box/carriage return added to the "Name" Field within the Windows 2003 Server > DHCP > Scope > Address Leases.
Conditions:
ASA using Windows 2003 Server as external DHCP Server.
VPN Clients update DNS using DHCP protocol through ASA to external Windows 2003 DHCP server.
ASA has "dhcp-client update dns" or "dhcp-client update dns server none" configured.
Workaround:
Don't update DNS through DHCP to an external server, i.e. configure "no dhcp-client update dns".
Further Problem Description:
The ASA sends the DHCP server a packet with malformed DHCP option 81 (Client Fully Qualified Domain Name) which causes the Windows 2003 Server to add a character to the 'Name' field in the DHCP Scope Address Leases seen on the Server. This character looks to be a carriage return.
Do you have "dhcp-client update dns" configured on your ASA?
If so, could you remove it and see if the ASA still sends the option 81?
Regards,
Nicolas
06-28-2011 01:55 AM
Hi Mark,
It seems that what you see has been reported under the following bug:
CSCsz07892 ASA Adds Character to Host Name Field of DHCP Request to Extrnl DHCP Srv
You can have a look at it's description from the following link:
Unfortunately as you can see from this link, this has been considered as a cosmetic issue and hasn't been fixed yet so I would advise you to contact your Cisco account team so that they can have it prioritize if this is important for you.
Regards,
Nicolas
PS: You might also want to have a look at the following bug as you could also be impacted by it: CSCsz07757 ASA sends malformed DNS update request to external DHCP Server.
06-28-2011 04:33 PM
I am thinking it may not be option 12 in the DHCP packet, but option 81. I have included a portion of the DHCP request from the ASA below:
Option: (t=53,l=1) DHCP Message Type = DHCP Request
Option: (53) DHCP Message Type
Length: 1
Value: 03
Option: (t=57,l=2) Maximum DHCP Message Size = 1152
Option: (57) Maximum DHCP Message Size
Length: 2
Value: 0480
Option: (t=61,l=42) Client identifier
Option: (61) Client identifier
Length: 42
Value: 00636973636F2D303032312E353537352E636131372D6D79...
Option: (t=54,l=4) Server Identifier = 192.168.8.3
Option: (54) Server Identifier
Length: 4
Value: C0A80803
Option: (t=50,l=4) Requested IP Address = 192.168.8.105
Option: (50) Requested IP Address
Length: 4
Value: C0A80869
Option: (t=12,l=11) Host Name = "myhostname"
Option: (12) Host Name
Length: 11
Value: 6D79686F73746E616D6500
Option: (t=51,l=4) IP Address Lease Time = 8 days
Option: (51) IP Address Lease Time
Length: 4
Value: 000A8C00
Option: (t=55,l=6) Parameter Request List
Option: (55) Parameter Request List
Length: 6
Value: 01060F2C0321
1 = Subnet Mask
6 = Domain Name Server
15 = Domain Name
44 = NetBIOS over TCP/IP Name Server
3 = Router
33 = Static Route
Option: (t=81,l=14) Client Fully Qualified Domain Name
Option: (81) Client Fully Qualified Domain Name
Length: 14
Value: 0400000A6D79686F73746E616D65
Flags: 0x04
0000 .... = Reserved flags: 0x00
.... 0... = Server DDNS: Some server updates
.... .1.. = Encoding: Binary encoding
.... ..0. = Server overrides: No override
.... ...0 = Server: Client
A-RR result: 0
PTR-RR result: 0
Client name: 0A6D79686F73746E616D65
End Option
Padding
Notice in option 81 the Client Name has a leading binary value of 0A (which is a new line): 0A6D79686F73746E616D65.
Does CSCsz07757 relate to that? Is there a way to have the ASA not include option 81 as part of the DHCP requests it makes?
Thank you.
06-29-2011 06:36 AM
Hi Mark,
This is exactly the issue described in , here is a copy of the bug release notes:
Symptom:
When VPN Clients connect to the ASA the ASA inserts an extra character or carriage return in the DHCP scope which causes the users' application to display dhcp information on two lines as opposed to one; the extra character causes a line feed on address resolution and automated tools can't handle the result.
This is also noticed as an extra symbol that looks like a box/carriage return added to the "Name" Field within the Windows 2003 Server > DHCP > Scope > Address Leases.
Conditions:
ASA using Windows 2003 Server as external DHCP Server.
VPN Clients update DNS using DHCP protocol through ASA to external Windows 2003 DHCP server.
ASA has "dhcp-client update dns" or "dhcp-client update dns server none" configured.
Workaround:
Don't update DNS through DHCP to an external server, i.e. configure "no dhcp-client update dns".
Further Problem Description:
The ASA sends the DHCP server a packet with malformed DHCP option 81 (Client Fully Qualified Domain Name) which causes the Windows 2003 Server to add a character to the 'Name' field in the DHCP Scope Address Leases seen on the Server. This character looks to be a carriage return.
Do you have "dhcp-client update dns" configured on your ASA?
If so, could you remove it and see if the ASA still sends the option 81?
Regards,
Nicolas
06-29-2011 08:14 AM
Thank you for your help! That was the problem. I turned off the "dhcp-client update dns" option, and then the ASA did not send option 81 as part of the DHCP request.
With option 81 not being sent, the hostname was updated correctly in the DHCP server without the invalid character represented as a box.
03-20-2012 03:42 AM
Sure that's an old discussion, but I also ran into the same issue and came into different conclusion. It looks to me that ASA behaves in RFC-complaint way, and MS DHCP server violates RFC.
RFC 4702, which describes DHCP option 81, defines two formats for transferring client name: plain ASCII and canonical wire format defined in RFC 1035.
Note that in this example, Encoding flag is set to 1, this means RFC1035 format is used. Byte 0x0A in the beginning of name in option 81 is not erroneous - this is length of next name part, 10 characters. This is strictly RFC4702-complaint. Unfortunately, MS DHCP server ignores "E" flag and processes the option as if client name was in ASCII.
Option: (t=81,l=14) Client Fully Qualified Domain Name Option: (81) Client Fully Qualified Domain Name Length: 14 Value: 0400000A6D79686F73746E616D65 Flags: 0x04 0000 .... = Reserved flags: 0x00 .... 0... = Server DDNS: Some server updates .... .1.. = Encoding: Binary encoding .... ..0. = Server overrides: No override .... ...0 = Server: Client A-RR result: 0 PTR-RR result: 0 Client name: 0A6D79686F73746E616D65 End Option Padding
Notice in option 81 the Client Name has a leading binary value of 0A (which is a new line): 0A6D79686F73746E616D65.
Does CSCsz07757 relate to that? Is there a way to have the ASA not include option 81 as part of the DHCP requests it makes?
Thank you.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide