My only IPSec exposure comes from configuring site-to-site VPNs (rather than client based connections). However, the "INVALID_ID_INFORMATION" response is something which I have seen before.
As part of the initial negotiation phase (it may even take place before any pre-shared keys are exchanged), an "ID" value is sent from the originator end as part of the "I'd like to establish a tunnel with you" phase. Contained within that transaction is an "ID" value. For site-to-site VPNs this is, more often than not, the public IP address and this is then matched to the correct IPSec definition on the receiving end of the connection. However, the ID doesn't have to be an IP address and for client-based connections in particular (where the IP address is likely to have been dynamically assigned) another value is used. Based on my own experience I've normally used an e-mail address. It doesn't have to be a real one, but the value in question must exist in the configuration at both ends.
From your log sample, this would appear to be a case where the client is trying to establish the connection, but the SnapGear is unable to match the credentials contained within the client connection request to a corresponding entry (which is how I would translate the first log entry).
Having said all that, I've looked at my own SnapGear and I can't see anything withing the L2TP configuation where you can add or amend a value like this one. Whereas if you look at the contruction of an IPSec entry, there is an "Optional Endpoint ID" entry which is what I would use to change the ID from the default IP address value when configuring a site-to-site IPSec entry.