key request from driver for 10.10.10.255 (we don't have a 10.x.x.x subnet)

[d-garnett]

3005 Concentrator

public interface e0 192.168.1.1

private interface e1 172.16.1.1 (also address of internal subnet/LAN)

in investigating VPN Client logs (Cisco Software Client - Unity) i ran across an issue when the client's remote access connection is configured for 'tunnel everything'. During Phase 2 negotiation after Mode Configuration parameters are recieved from the concentrator, the client recieves 2 request from driver: One for 192.168.1.1 (public interface of 3005) which is good, but the other is for 10.10.10.255 and we do not have a 10.x.x.x subnet. I checked the IP and ARP Tables on the concentrator just to be certain but no 10x.x.x subnet. There are no connectivity problems as everything works fine, but i am wondering where does 10.x.x.x come from. Client addresses are assigned from an internal pool same as LAN (172.16.1.x). This does not occur when using Split Tunneling.

37 13:36:28.540 01/11/03 Sev=Info/5 IKE/0x6300000E

MODE_CFG_REPLY: Attribute = APPLICATION_VERSION, value = Cisco Systems, Inc./VPN 3000 Concentrator Series Version 3.1.Rel built by vmurphy on Aug 06 2001 13:47:37

38 13:36:28.540 01/11/03 Sev=Info/4 CM/0x63100019

Mode Config data received

39 13:36:28.540 01/11/03 Sev=Info/5 IKE/0x63000055

Received a key request from Driver for IP address 192.168.1.1, GW IP = 192.168.1.1

40 13:36:28.540 01/11/03 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK QM *(HASH, SA, NON, ID, ID) to 192.168.1.1

<b>

41 13:36:28.540 01/11/03 Sev=Info/5 IKE/0x63000055

Received a key request from Driver for IP address 10.10.10.255, GW IP = 192.168.1.1

42 13:36:28.540 01/11/03 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK QM *(HASH, SA, NON, ID, ID) to 192.168.1.1

</b>

43 13:36:28.650 01/11/03 Sev=Info/4 IPSEC/0x63700014

Deleted all keys

[gfullage]

I just tried this on my VPN client to a lab concentrator and I get the same message, so I don't think it's anything to worry about. I've contacted the developers to see exactly why this happens, I'll get back to you with an answer when I hear from them.

[d-garnett]

thanks

i have also seen this in the Cisco Press: Troubleshooting Remote Access Networks book (page 692) and on a few log debugs around here on this site. thanks again for looking out.

[engel]

Kind of interesting output. Hope that is not any form of attack ......

Looking for any wisdom from the developer.

Best Regards,

Engel

[b-pelphrey]

This may be WAY off the mark, but what subnet is the remote client on? Does the remote client ever need to talk to a 10.10.10.x address? If it is tunneling everything maybe the client is doing some type of broadcast looking for this 10.10.10.255, and you are just getting that traffic because it is tunneling everything.

Not sure, but just trying to get eveyone's motors running....Just a thought!!.....

[d-garnett]

the remote client is a non-networked single PC dialing up via modem

there are no 10.10.10.x subnets in the entire network.

tunnel everything (to 0.0.0.0) parameters are pushed down from the Concentrator. i don't know think the client is looking for a 10.10.10.x subnet since it recieves a key request for it from the Concentrator. My main concern is that the client sends back info to the Concentrator about it

[gfullage · Accepted solution]

OK, official word is:

The 10.10.10.255 IP is hardcoded and is used for the public to public IKE SA establishment.

Basically two tunnels are built when you connect, one for the internal network (0.0.0.0) and one to the public address of the concentrator. This 10.10.10.255 address is used during that negotiation, not sure why, it's just the way the client and the concentrator were designed.

It's nothing to worry about, it's just the way the coding was done, you will always see this address used for building this particular SA.

[d-garnett]

i am glad that i can breath a little easier, now. Thanks for all your help. That seems a little strange based on the fact the Concentrator has no IP's on the interfaces out the box. i guess the programmers expected everyone to use 10.10.10.0/24 as thier internal subnet. i wonder is that the same as when installing the 12.2YJ (or T, i am not sure) image on a router and reloading. There is a default startup configuration of 10.10.10.1 as the e0 ip address. Thanks again for your insight.

[gfullage]

There's no default as far as I know. I think they just chose that address more because no-one would use it (the 10.10.10.255 address specifically). It does seem a bit strange to me, it seems like a bit of a kludge or that they just found it easier to do it this way. Not sure why they couldn't have used the outside IP address which is what you're building the tunnel to anyway, but hey, I just work here :-)