<html><head>
<meta name="Generator" content="Novell Groupwise Client (Version 14.0.2 Build: 120664)">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head>
<body style="font: 10pt/normal Tahoma; font-size-adjust: none; font-stretch: normal;"><div class="GroupWiseMessageBody" id="GroupWiseSection_1439471969000_f.langner@isam-ag.de_AEC16710180A0000A2F10020AFF0489B_"><div>Hi,</div><div><br></div><div>I know this is a topic that has been discussed several times before, but it seems that no solution has been presented so far.</div><div><br></div><div>Situation:</div><div>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.</div><div><br></div><div>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!</div><div><br></div><div>This is what has been reported to the UTM's log file during connections establishment:</div><div><br></div><div>2015:08:13-15:42:21 <deviceid1> pluto[14483]: | *received 336 bytes from 80.187.109.145:500 on eth1<br>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]<br>2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from 80.187.109.145:500: ignoring Vendor ID payload [16f6ca16e4a4066d83821a0f0aeaa862]<br>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]<br>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]<br>2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from 80.187.109.145:500: received Vendor ID payload [RFC 3947]<br>2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from 80.187.109.145:500: ignoring Vendor ID payload [FRAGMENTATION 80000000]<br>2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from 80.187.109.145:500: received Vendor ID payload [Dead Peer Detection]<br>2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from 80.187.109.145:500: ignoring Vendor ID payload [3b9031dce4fcf88b489a923963dd0c49]<br>2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from 80.187.109.145:500: ignoring Vendor ID payload [f14b94b7bff1fef02773b8c49feded26]<br>2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from 80.187.109.145:500: ignoring Vendor ID payload [166f932d55eb64d8e4df4fd37e2313f0d0fd8451]<br>2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from 80.187.109.145:500: ignoring Vendor ID payload [8404adf9cda05760b2ca292e4bff537b]<br>2015:08:13-15:42:21 <deviceid1> pluto[14483]: packet from 80.187.109.145:500: ignoring Vendor ID payload [Cisco-Unity]<br>2015:08:13-15:42:21 <deviceid1> pluto[14483]: | instantiated "D_REF_IpsRoaVpnc2stmp2_CzigvvkMjg-0" for 80.187.109.145<br>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<br>2015:08:13-15:42:21 <deviceid1> pluto[14483]: | *received 293 bytes from 80.187.109.145:500 on eth1<br>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<br>2015:08:13-15:42:21 <deviceid1> pluto[14483]: | *received 536 bytes from 80.187.109.145:11352 on eth1<br>2015:08:13-15:42:21 <deviceid1> pluto[14483]: | *received 536 bytes from 80.187.109.145:11352 on eth1<br>2015:08:13-15:42:21 <deviceid1> pluto[14483]: | *received 536 bytes from 80.187.109.145:11352 on eth1<br>2015:08:13-15:42:21 <deviceid1> pluto[14483]: | *received 84 bytes from 80.187.109.145:11352 on eth1<br>2015:08:13-15:42:21 <deviceid1> pluto[14483]: | NAT-T: new mapping 80.187.109.145:500/11352)<br>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>'<br>2015:08:13-15:42:21 <deviceid1> pluto[14483]: "D_REF_IpsRoaVpnc2stmp2_CzigvvkMjg-0"[3] 80.187.109.145:11352 #47: crl not found<br>2015:08:13-15:42:21 <deviceid1> pluto[14483]: "D_REF_IpsRoaVpnc2stmp2_CzigvvkMjg-0"[3] 80.187.109.145:11352 #47: certificate status unknown<br>2015:08:13-15:42:21 <deviceid1> pluto[14483]: | instantiated "D_REF_MPvXDPqvoz_pzDtSZsmoS-0" for 80.187.109.145<br>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}<br>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<br>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<br>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<br></div><div><br>2015:08:13-15:43:00 <deviceid1> pluto[14483]: | *received 76 bytes from 80.187.109.145:11352 on eth1<br>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<br>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<br></div><div><br></div><div><br></div><div>"IKE fragmentation" has to be set to "force" (instead of "enable"), otherwise the connect will stop after "<!--StartFragment-->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.</div><div><br></div><div>An other observation is, that the NCP client seems to use a port <!--StartFragment-->different from 500, because the UTM logs "NAT-T: new mapping 80.187.109.145:<font style="background-color: rgb(255, 255, 0);"><strong>19596</strong></font>/1340". Using the Shrew client, it logs "<!--StartFragment-->NAT-T: new mapping 80.187.109.145:<font style="background-color: rgb(255, 255, 0);"><strong>500</strong></font>/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...</div><div><br></div><div>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!<br></div><span id="GWSignatureSent" style="padding-right: 0px; padding-left: 0px; margin-bottom: 5px; display: block;"><span style="display: block;"><br><span style="font-size: 10pt; display: inline-block; -ms-word-wrap: normal;">
<div>Regards</div>
<div>Frank</div>
<div>-----------------------------------------------------------------------------</div></span></span></span><span style="margin-bottom: 5px; display: block;"><br></span></div><BR>
<div>
<font size="2" face="Lucida Sans">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</font>
</div>
</BODY></HTML>