[Vpn-help] Trying to connect with FVS338 [invalid message from gateway]

Matthew Grooms mgrooms at shrew.net
Tue Jun 16 12:12:23 CDT 2009


Matthew Grooms wrote:
> Fabio Cigoi wrote:

Crap. I misread this email. Just to clarify for others on the list, if 
you see this error it typically means the gateway is sending a different 
type than the client is expecting. The Identity types and values should 
be provided by the person who manages the VPN gateway. But in a pinch, 
you can use the following procedure to 'discover' the peer ID type and 
value under most circumstances.

Both the type and value need to match on both ends of the connection for 
authentication to succeed. The client sends an ID that is verified by 
the gateway and the gateway sends and ID that is verified by the client. 
The only exception is Hybrid mode where the client ID is typically null 
or ignored since Xauth would be used for both client identification and 
authentication. However, a server is still authenticated by the client.

If you see an 'invalid message from gateway' and log output similar to 
the whats shown below, you are probably bumping into what is referred to 
as a peer identity mismatch ...

<< : identification payload
!! : phase1 id type mismatch ( received fqdn but expected user-fqdn )
DB : phase1 resend event canceled ( ref count = 1 )
ii : phase1 removal before expire time
DB : phase1 deleted ( obj count = 0 )

Interpreting this output is rather simple. The gateway is sending Fully 
Qualified Domain Name ( FQDN ) but the client was expecting to receive a 
User Fully Qualified Domain Name ( UFQDN ). In other words, the client 
tab has the Authentication / 'Remote Identity type' set to 'User Fully 
Qualified Domain Name' when it should be set to 'Fully Qualified Domain 
Name' for this gateway.

Now that we know how to determine the ID type being sent by the gateway, 
what if we don't know the value? After changing the type to match what 
is being sent by the gateway, enter a bogus value and try the connection 
again. The output should look something like this ...

<< : identification payload
!! : phase1 id mismatch
!! : received = fqdn vpngw.shrew.net
!! : expected = fqdn bogus.fqdn.com
DB : phase1 resend event canceled ( ref count = 1 )
ii : phase1 removal before expire time
DB : phase1 deleted ( obj count = 0 )

We now know both the type and value being sent by the gateway. If we set 
the the Remote ID value to match the value received, 'vpngw.shrew.net', 
we should be able to connect successfully. Your log output should now 
look something like this ...

09/06/16 11:44:13 << : identification payload
09/06/16 11:44:13 ii : phase1 id match
09/06/16 11:44:13 ii : received = fqdn vpngw.shrew.net

Hope this helps,

-Matthew

>> Hi all,
>>
>> After many attempts to follow the How-to published on Shrew Soft's
>> website to connect to a Netgear FVS338 router from the Linux version
>> of the client, many errors and many solutions found, during which the
>> only message was "timeout during negotiation", I managed to turn it
>> into a "invalid message from gateway" on the GUI, and I found a
>> "phase1 id type mismatch ( received fqdn but expected user-fqdn )" Has
>> anyone bumped into this message before and managed to understand how
>> to sort it out ?
>>
> 
> Hi Fabio,
> 
> This means that the clients ID is being accepted by the gateway but the 
> gateways ID is being rejected by the client. My advice would be to set 
> the Remote ID type to User Fully Qualified Domain Name ( because thats 
> whats being sent ) and try to connect again. At that point, if you see 
> an error message about the ID being rejected, the log will also contain 
> the value sent by gateway now that the types match.
> 
> Good luck,
> 
> -Matthew
> _______________________________________________
> vpn-help mailing list
> vpn-help at lists.shrew.net
> http://lists.shrew.net/mailman/listinfo/vpn-help




More information about the vpn-help mailing list