[vpn-help] client v2.2.2 and UMTS

Thu Aug 13 10:16:53 CDT 2015

Hi,

I know this is a topic that has been discussed several times before,
but it seems that no solution has been presented so far.

Situation:
Shrew Client 2.2.2 installed on a notebook. This notebook can connect
to our IPSEC gateway (a Sophos UTM) by LAN and WLAN without problems. If
the notebook is connected to the internet by using a UMTS device (e.g.
iPhone), the IPSEC tunnel can not be established.

On the same notebook, replacing the Shrew Client with the "NCP Secure
Client" (v 9.2.1) fixes this issue. That means: the NCP client can
establish a connection via UMTS just fine, the Shrew Client can not!

This is what has been reported to the UTM's log file during connections
establishment:

2015:08:13-15:42:21 <deviceid1> pluto[14483]: | *received 336 bytes
from 80.187.109.145:500 on eth1
2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from
80.187.109.145:500: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-00]
2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from
80.187.109.145:500: ignoring Vendor ID payload
[16f6ca16e4a4066d83821a0f0aeaa862]
2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from
80.187.109.145:500: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-02_n]
2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from
80.187.109.145:500: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-03]
2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from
80.187.109.145:500: received Vendor ID payload [RFC 3947]
2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from
80.187.109.145:500: ignoring Vendor ID payload [FRAGMENTATION 80000000]
2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from
80.187.109.145:500: received Vendor ID payload [Dead Peer Detection]
2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from
80.187.109.145:500: ignoring Vendor ID payload
[3b9031dce4fcf88b489a923963dd0c49]
2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from
80.187.109.145:500: ignoring Vendor ID payload
[f14b94b7bff1fef02773b8c49feded26]
2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from
80.187.109.145:500: ignoring Vendor ID payload
[166f932d55eb64d8e4df4fd37e2313f0d0fd8451]
2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from
80.187.109.145:500: ignoring Vendor ID payload
[8404adf9cda05760b2ca292e4bff537b]
2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from
80.187.109.145:500: ignoring Vendor ID payload [Cisco-Unity]
2015:08:13-15:42:21 <deviceid1> pluto[14483]: | instantiated
"D_REF_IpsRoaVpnc2stmp2_CzigvvkMjg-0" for 80.187.109.145
2015:08:13-15:42:21 <deviceid1> pluto[14483]:
"D_REF_IpsRoaVpnc2stmp2_CzigvvkMjg-0"[3] 80.187.109.145 #47: responding
to Main Mode from unknown peer 80.187.109.145
2015:08:13-15:42:21 <deviceid1> pluto[14483]: | *received 293 bytes
from 80.187.109.145:500 on eth1
2015:08:13-15:42:21 <deviceid1> pluto[14483]:
"D_REF_IpsRoaVpnc2stmp2_CzigvvkMjg-0"[3] 80.187.109.145 #47:
NAT-Traversal: Result using RFC 3947: peer is NATed
2015:08:13-15:42:21 <deviceid1> pluto[14483]: | *received 536 bytes
from 80.187.109.145:11352 on eth1
2015:08:13-15:42:21 <deviceid1> pluto[14483]: | *received 536 bytes
from 80.187.109.145:11352 on eth1
2015:08:13-15:42:21 <deviceid1> pluto[14483]: | *received 536 bytes
from 80.187.109.145:11352 on eth1
2015:08:13-15:42:21 <deviceid1> pluto[14483]: | *received 84 bytes from
80.187.109.145:11352 on eth1
2015:08:13-15:42:21 <deviceid1> pluto[14483]: | NAT-T: new mapping
80.187.109.145:500/11352)
2015:08:13-15:42:21 <deviceid1> pluto[14483]:
"D_REF_IpsRoaVpnc2stmp2_CzigvvkMjg-0"[3] 80.187.109.145:11352 #47: Peer
ID is ID_USER_FQDN: '<myUserID>'
2015:08:13-15:42:21 <deviceid1> pluto[14483]:
"D_REF_IpsRoaVpnc2stmp2_CzigvvkMjg-0"[3] 80.187.109.145:11352 #47: crl
not found
2015:08:13-15:42:21 <deviceid1> pluto[14483]:
"D_REF_IpsRoaVpnc2stmp2_CzigvvkMjg-0"[3] 80.187.109.145:11352 #47:
certificate status unknown
2015:08:13-15:42:21 <deviceid1> pluto[14483]: | instantiated
"D_REF_MPvXDPqvoz_pzDtSZsmoS-0" for 80.187.109.145
2015:08:13-15:42:21 <deviceid1> pluto[14483]:
"D_REF_MPvXDPqvoz_pzDtSZsmoS-0"[1] 80.187.109.145:11352 #47: deleting
connection "D_REF_IpsRoaVpnc2stmp2_CzigvvkMjg-0"[3] instance with peer
80.187.109.145 {isakmp=#0/ipsec=#0}
2015:08:13-15:42:21 <deviceid1> pluto[14483]:
"D_REF_MPvXDPqvoz_pzDtSZsmoS-0"[1] 80.187.109.145:11352 #47: we have a
cert and are sending it
2015:08:13-15:42:21 <deviceid1> pluto[14483]:
"D_REF_MPvXDPqvoz_pzDtSZsmoS-0"[1] 80.187.109.145:11352 #47: Dead Peer
Detection (RFC 3706) enabled
2015:08:13-15:42:21 <deviceid1> pluto[14483]:
"D_REF_MPvXDPqvoz_pzDtSZsmoS-0"[1] 80.187.109.145:11352 #47: sent MR3,
ISAKMP SA established

2015:08:13-15:43:00 <deviceid1> pluto[14483]: | *received 76 bytes from
80.187.109.145:11352 on eth1
2015:08:13-15:43:00 <deviceid1> pluto[14483]:
"D_REF_MPvXDPqvoz_pzDtSZsmoS-0"[1] 80.187.109.145:11352 #47: next
payload type of ISAKMP Hash Payload has an unknown value: 85
2015:08:13-15:43:00 <deviceid1> pluto[14483]:
"D_REF_MPvXDPqvoz_pzDtSZsmoS-0"[1] 80.187.109.145:11352 #47: malformed
payload in packet

"IKE fragmentation" has to be set to "force" (instead of "enable"),
otherwise the connect will stop after "NAT-Traversal: Result using RFC
3947: peer is NATed". In this case the next packet received is of length
76 bytes, instead of 1.692 bytes (in total of the 4 packets). Using the
NCP client, this packet is of size 1580 byte.

An other observation is, that the NCP client seems to use a port
different from 500, because the UTM logs "NAT-T: new mapping
80.187.109.145:19596/1340". Using the Shrew client, it logs "NAT-T: new
mapping 80.187.109.145:500/11352". I have no idea whether this might be
important, and on the other hand I did not find an option to modify the
port on the client side. Sometimes the NCP client seems to use port 500
also and it still works, which might lead to the conclusion that this
port oddity is not important...

Any ideas how to make the Shrew Client work in combination with an UMTS
connection? It seems that the NCP client is doing something different
and would be very very nice to have this feature implemented into the
Shrew Client also!

Regards
Frank
-----------------------------------------------------------------------------

iSAM AG, Alexanderstr. 46, 45472 Mülheim an der Ruhr
Registergericht: Duisburg, HRB 16160
Vorstand: Dr. Jürgen Hellmich (Vorsitz), Bernd Mann, Bernd Jotzo
Vorsitzender des Aufsichtsrates: Bernd Schwarz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.shrew.net/pipermail/vpn-help/attachments/20150813/b74f5fe0/attachment.html>