Hi Alexis. My client is behind a router (it is *not* connected directly to the internet). So the router has to route the return packet. It therefore must come back to the originating port (namely 26891 in this example).
-----------------------------------~~~~~~~----------------------------- Doing what you love is Freedom. | o o | Kevin Pickard Loving what you do is Happiness. | ^ | [email protected] ------------------------------^^^-----------^^^------------------------ On Sat 10/11/20 10:42 AM , Alexis La Goutte [email protected] sent: > Hi Kevin, > > Your Client is between a router ? or directly connected to Internet ? > > Regards, > > On Fri, Nov 19, 2010 at 7:07 PM, wrote: > Thanks for the response Alexis. > I can not easily test from another location but I did > identify where there is a problem. I managed to run a > Wireshark trace outside of the router at the client side and I see > that the Netgear *is* responding. The problem is > that it is responding to port 500 when it received the request from > port 26891! So the router here rightly does not > route the response. So the flow is as follows. > Client SrcPort(26891) -> DstPort(500) ISAKMP Req > Netgear > Client DstPort(500) Hi kevin, > > > > I received your message, have you tested from another Internet > > access? > > Because it is very strange to not receive answer from router > > Regards, > > On Thu, Nov 18, 2010 at 7:12 PM, wrote: > > Hello Alexis. Sorry to bother you. I was just wondering if > you > > received the message below sent yesterday (and > > followup with Netgear config) and if you had any further ideas? > You > > helped me get to the point where it is almost > > negotiating. Thank you very much for that. > > > > > -----------------------------------~~~~~~~----------------------------- > > Doing what you love is Freedom. | o o | Kevin Pickard > > Loving what you do is Happiness. | ^ | > > > > > ------------------------------^^^-----------^^^------------------------ > > ----- Original Message ----- > > From: > > To: "Alexis La Goutte" > > Sent: Wed 10/11/17 2:46 PM > > Subject: Fwd: Re: Re: [vpn-help] Netgear > > FVS318 > > Hi Alexis. I have not included the Shrew debug before > because > > it just shows the retry of the ISAKMP packet > > send (last few lines). I have now included it below. I also am > > running Wireshark on the client side and all I see > > is the ISAKMP packet going out with no response coming back in as > > well. So everything important right now is > > happening on the Netgear router side. Based on my earlier logs > from > > the Netgear it looks like it is trying to send > > a response but for whatever reason it is not getting back to the > > client. As I said, my client is also behind a NAT > > router. Is there something else that I need to setup in the > Netgear > > so it knows how to reach the client behind the > > router or is there something else I need to configure on the > client > > so it can tell the Netgear how to get back to > > it? > > Once again thanks for all your help. > > 10/11/17 14:37:39 ## : IKE Daemon, ver 2.1.7 > > 10/11/17 14:37:39 ## : Copyright 2010 Shrew Soft Inc. > > 10/11/17 14:37:39 ## : This product linked OpenSSL 0.9.8h 28 May > > 2008 > > 10/11/17 14:37:39 ii : opened 'C:Program FilesShrewSoftVPN > > Clientdebugiked.log' > > 10/11/17 14:37:39 ii : rebuilding vnet device list ... > > 10/11/17 14:37:40 ii : device ROOTVNET000 disabled > > 10/11/17 14:37:40 ii : network process thread begin ... > > 10/11/17 14:37:40 ii : pfkey process thread begin ... > > 10/11/17 14:37:40 ii : ipc server process thread begin ... > > 10/11/17 14:37:43 ii : ipc client process thread begin ... > > 10/11/17 14:37:43 > : key exchange payload > > 10/11/17 14:37:43 >> : nonce payload > > 10/11/17 14:37:43 >> : identification payload > > 10/11/17 14:37:43 >> : vendor id payload > > 10/11/17 14:37:43 ii : local supports nat-t ( draft v00 ) > > 10/11/17 14:37:43 >> : vendor id payload > > 10/11/17 14:37:43 ii : local supports nat-t ( draft v01 ) > > 10/11/17 14:37:43 >> : vendor id payload > > 10/11/17 14:37:43 ii : local supports nat-t ( draft v02 ) > > 10/11/17 14:37:43 >> : vendor id payload > > 10/11/17 14:37:43 ii : local supports nat-t ( draft v03 ) > > 10/11/17 14:37:43 >> : vendor id payload > > 10/11/17 14:37:43 ii : local supports nat-t ( rfc ) > > 10/11/17 14:37:43 >> : vendor id payload > > 10/11/17 14:37:43 ii : local supports FRAGMENTATION > > 10/11/17 14:37:43 >> : vendor id payload > > 10/11/17 14:37:43 ii : local supports DPDv1 > > 10/11/17 14:37:43 >> : vendor id payload > > 10/11/17 14:37:43 ii : local is SHREW SOFT compatible > > 10/11/17 14:37:43 >> : vendor id payload > > 10/11/17 14:37:43 ii : local is NETSCREEN compatible > > 10/11/17 14:37:43 >> : vendor id payload > > 10/11/17 14:37:43 ii : local is SIDEWINDER compatible > > 10/11/17 14:37:43 >> : vendor id payload > > 10/11/17 14:37:43 ii : local is CISCO UNITY compatible > > 10/11/17 14:37:43 >= : cookies 7b05d12fcf86a8d3:0000000000000000 > > 10/11/17 14:37:43 >= : message 00000000 > > 10/11/17 14:37:43 -> : send IKE packet MAILFILTERGATEWAY WARNING: > > NUMERICAL LINKS ARE OFTEN MALICIOUS: 192.168.1.83:500 [4] [5] -> > > MAILFILTERGATEWAY WARNING: NUMERICAL LINKS ARE OFTEN MALICIOUS: > > 206.248.160.8:500 [5] [6] ( 554 bytes ) > > 10/11/17 14:37:43 DB : phase1 resend event scheduled ( ref count = > 2 > > ) > > 10/11/17 14:37:48 -> : resend 1 phase1 packet(s) MAILFILTERGATEWAY > > WARNING: NUMERICAL LINKS ARE OFTEN MALICIOUS: 192.168.1.83:500 [6] > [7] -> > > MAILFILTERGATEWAY WARNING: NUMERICAL LINKS ARE OFTEN MALICIOUS: > > 206.248.160.8:500 [7] [8] > > > > > -----------------------------------~~~~~~~----------------------------- > > Doing what you love is Freedom. | o o | Kevin Pickard > > Loving what you do is Happiness. | ^ | > > > > > ------------------------------^^^-----------^^^------------------------ > > On Wed 10/11/17 2:12 PM , Alexis La Goutte sent: > > > Hi, > > > > > > No, the communications never use TCP, ISAKMP use UDP (Port 500). > > > > > > No trace in Shrew Debug ? > > > > > > Regards, > > > On Wed, Nov 17, 2010 at 7:51 PM, wrote: > > > Hi Alexis. Thanks again for your help. > > > Well I noticed that there was a mismatch in the Key Group > so > > I > > > changed my Netgear to use DH Group 2 as this is > > > what the Shrew client was using for DH exchange. I also > explicitly > > > specified 3DES as the cipher algorithm on the > > > client side rather than auto because I was seeing a lot of > trying > > > the different options on the Netgear side until > > > it settled on 3DES anyway. > > > So now things are looking like they are getting further > > along > > > (see Netgear log below). It looks though like > > > the Netgear is trying to send back a response (the TX >> AM_R1 > > line) > > > but I am not seeing it at the client side. Is > > > there something else I should be doing as the client is behind a > > NAT > > > router? Should the communications from the > > > client not be over TCP rather than UDP to make this work? > > > Again thanks for all your help. > > > Wed, 11/17/2010 13:43:00 - TekSavvy IPsec:Receive Packet > > > address:0x1396850 from 216.254.149.98 > > > Wed, 11/17/2010 13:43:00 - TekSavvy IKE:Peer Initialized IKE > > > Aggressive Mode > > > Wed, 11/17/2010 13:43:00 - TekSavvy IKE:RX > AM_R1 : > > 216.254.149.98 > > > Wed, 11/17/2010 13:43:00 - TekSavvy IPsec:inserting event > > > EVENT_RETRANSMIT, timeout in 10 seconds for #4 > > > Wed, 11/17/2010 13:43:04 - TekSavvy IPsec:event after this is > > > EVENT_RETRANSMIT in 4 seconds > > > Wed, 11/17/2010 13:43:04 - TekSavvy IPsec:handling event > > > EVENT_RETRANSMIT for d8fe9562 "Client_Shrew_tmp2" #3 > > > Wed, 11/17/2010 13:43:04 - TekSavvy IPsec:inserting event > > > EVENT_RETRANSMIT, timeout in 20 seconds for #3 > > > > > > > > > -----------------------------------~~~~~~~----------------------------- > > > Doing what you love is Freedom. | o o | Kevin Pickard > > > Loving what you do is Happiness. | ^ | > > > > > > > > > ------------------------------^^^-----------^^^------------------------ > > > On Wed 10/11/17 12:31 PM , Alexis La Goutte sent: > > > > Hi Kevin, > > > > The identifier Information (fvs_remote.com [8] [11] [4] [1] > and > > > fvs_local.com [9] [12] [5] [2]) > > > > are actual values to be used, not need to resolve this > address. > > > > Check your phase1 parameter (ISAKMP) > > > > > > > > Regards, > > > > > > > > On Wed, Nov 17, 2010 at 6:25 PM, wrote: > > > > Thank you Alexis. I went through the VPN Wizard again > and > > > > followed the steps at the link you provided. I then > > > > rebooted my router to make sure it was starting with the > proper > > > > configuration. Now it appears that my router is no > > > > longer flagging the ISAKMP packets as suspicious and tossing > > them > > > > (which is good). In fact it looks like my router > > > > is actually trying to process the packets now. But it is > having > > > > trouble with what it is seeing, based on its own > > > > internal logs (below)...and a response is not being sent back > to > > > the > > > > Shrew client. > > > > My question now is, according to the link you provided, > I > > > was > > > > to set the Identifier information fields to > > > > fvs_remote.com [10] [13] [6] [4] and fvs_local.com [11] [14] > [7] [5]. Are > > these just > > > examples or > > > > are they the actual values to be used? Should these > > > > not resolve to real addresses? As can be seen below the FQDN > of > > > > fvs_remote.com [12] [15] [8] [6] is being sent by the Shrew > client in > > > > the ISAKMP packet. The Netgear then complains about not having > a > > > > connection. Is this because this address does not > > > > resolve? > > > > By the way, the Shrew client is on a network behind a > > router > > > > so is NAT. > > > > Anyway, below is the log from my Netgear. On the Shrew > > side > > > I > > > > only see the ISAKMP packets being sent out every > > > > 5 seconds without any response coming back. > > > > Wed, 11/17/2010 10:44:22 - TekSavvy IKE:Trying Dynamic IP > > > Searching > > > > Wed, 11/17/2010 10:44:28 - TekSavvy IPsec:Receive Packet > > > > address:0x1396850 from 216.254.149.98 > > > > Wed, 11/17/2010 10:44:28 - TekSavvy IKE:Peer Initialized IKE > > > > Aggressive Mode > > > > Wed, 11/17/2010 10:44:28 - TekSavvy IKE:RX Hi Kevin, > > > > > > > > > > There is a VPN wizard in your FVS318v1 ? > > > > > > > > > > Because use VPN Wizard and information in this blog > > > > > > > > > > > > > > > http://blog.igut.fr/post/2009/02/07/Client-VPN-IPSec-Shrew-avec-Routeur-VPN > [13] > > [16] > > > [9] > > > > [9] > > > > > -NETGEAR[1] > > > > > And it should work ! > > > > > > > > > > Regards, > > > > > > > > > > On Mon, Nov 15, 2010 at 2:05 PM, Kevin Pickard wrote: > > > > > Thanks for the response Alexis. So have you > managed > > > to > > > > > get a FVS318v1 to work? Do you know what configuration I > > should > > > > use? > > > > > As I said in my initial post, my attempts at > > > > configuring > > > > > it have failed (see below). > > > > > At 03:59 AM 2010-11-15, Alexis La Goutte wrote: > > > > > >Hi Kevin, > > > > > > > > > > > >Yes, it work but you should not use the Xauth & ModeConfig > > (no > > > > > available in FVS318v1) > > > > > > > > > > > >Regards, > > > > > > > > > > > > > > > > > >On Sat, Nov 13, 2010 at 11:19 PM, Kevin Pickard wrote: > > > > > > I take it no-one else has any experience with > this? > > > > > Andreas was the only one to respond but his FVS318 appears > to > > be > > > a > > > > > newer version and is completely different from mine. I have > > the > > > > older > > > > > v1 hardware (FVS318v1). Anyone? > > > > > >At 16:59:21 2010-10-26, wrote: > > > > > >>Message: 2 > > > > > >>Date: Tue, 26 Oct 2010 16:59:21 +0200 > > > > > >>From: > > > > > >>Subject: Re: [vpn-help] Netgear FVS318 > > > > > >>To: > > > > > >>Message-ID: > > > > > >>Content-Type: text/plain; charset="iso-8859-1"; > > > Format="flowed"; > > > > > >> DelSp="Yes" > > > > > >> > > > > > >>Zitat von : > > > > > >> > > > > > >>> Hello. Does anyone know if the Shrew client will > > > work > > > > > with the > > > > > >>> Netgear FVS318 router? > > > > > >>> > > > > > >>> I have scanned the archives and I have found > > > > references > > > > > to the > > > > > >>> FVG318 but nothing specific about the FVS318. I have > seen > > > > > references > > > > > >>> to needing Mode and Xauth enabled to get the FVS318 to > > work > > > > but > > > > > >>> neither of those options exist on the FVS318 (that I can > > > > find). > > > > > So I > > > > > >>> think those people are confusing the FVS318 with another > > > > model. > > > > > >>> > > > > > >>> Has anyone been able to get the Netgear FVS318 > (V1 > > > > > hardware > > > > > >>> running V2.4 firmware) to work with the Shrew client? > > > > > >>> > > > > > >>> My initial attempts at trying various > > configurations > > > > > have only > > > > > >>> resulted in security warnings on my FVS318 indicating > that > > > UDP > > > > > >>> packets (from the Shrew Client) are being tossed because > > > they > > > > > >>> contain 'Suspicious UDP Data'. I have configured > > to > > > > use > > > > > PSK. On the > > > > > >>> client > > > > > >>> side, via Wireshark, I only see the ISAKMP packet being > > sent > > > > out > > > > > >>> (this is the one being tossed by the FVS318) at 5 second > > > > > intervals. > > > > > >>> The > > > > > >>> Shrew client itself shows "bringing up tunnel ...", then > > > > > eventually > > > > > >>> followed by "negotiation timout [sic] occurred" after > the > > > > ISAKMP > > > > > >>> packet has been sent 4 times. > > > > > >> > > > > > >>Only some guess: > > > > > >>If the netgear has some form of firewall you maybe need to > > > allow > > > > > >>inbound UDP port 500 and if using UDP encapsulation port > > 4500 > > > as > > > > > well > > > > > >>to get the tunnel up. > > > > > >> > > > > > >>Regards > > > > > >> > > > > > >>Andreas > > > > > >> > > > > > >> > > > > > >>-------------- next part -------------- > > > > > >>A non-text attachment was scrubbed... > > > > > >>Name: smime.p7s > > > > > >>Type: application/pkcs7-signature > > > > > >>Size: 6046 bytes > > > > > >>Desc: S/MIME Cryptographic Signature > > > > > >>URL: > > > > > >> > > > > > >>------------------------------ > > > > > >> > > > > > >>_______________________________________________ > > > > > >>vpn-help mailing list > > > > > >> > > > > > >>http://lists.shrew.net/mailman/listinfo/vpn-help [14] [17] > [10] > > [10] > > > [19] > > > > > >> > > > > > >> > > > > > >>End of vpn-help Digest, Vol 49, Issue 25 > > > > > >>**************************************** > > > > > > > > > > > > > > > > > > > > >-----------------------------------~~~~~~~----------------------------- > > > > > > Doing what you love is Freedom. | o o | Kevin Pickard > > > > > > Loving what you do is Happiness. | ^ | > > > > > > > > > > > > > > > > > > > > >------------------------------^^^-----------^^^------------------------ > > > > > >_______________________________________________ > > > > > >vpn-help mailing list > > > > > > > > > > > >http://lists.shrew.net/mailman/listinfo/vpn-help [15] [18] > [11] > > [11] [24] > > > > > > > > > > > > > > > > > > > > -----------------------------------~~~~~~~----------------------------- > > > > > Doing what you love is Freedom. | o o | Kevin Pickard > > > > > Loving what you do is Happiness. | ^ | > > > > > > > > > > > > > > > > > > > > ------------------------------^^^-----------^^^------------------------ > > > > > > > > > > > > > > > Links: > > > > > ------ > > > > > [1] > > > > > > > > > > > > > > > http://blog.igut.fr/post/2009/02/07/Client-VPN-IPSec-Shrew-avec-Routeur-VPN > [16] > > [19] > > > [12] > > > > [12] > > > > > -NETGEAR[15] > > > > > > Links: > > ------ > > [5] http://192.168.1.83:500 [17] > > [6] http://206.248.160.8:500 [18] > > [7] http://192.168.1.83:500 [19] > > [8] http://206.248.160.8:500 [20] > > [11] http://fvs_remote.com [21] > > [12] http://fvs_local.com [22] > > [13] http://fvs_remote.com [23] > > [14] http://fvs_local.com [24] > > [15] http://fvs_remote.com [25] > > [16] > > > http://blog.igut.fr/post/2009/02/07/Client-VPN-IPSec-Shrew-avec-Routeur-VPN > [26] > > [17] http://lists.shrew.net/mailman/listinfo/vpn-help [27] > > [18] http://lists.shrew.net/mailman/listinfo/vpn-help [28] > > [19] > > > http://blog.igut.fr/post/2009/02/07/Client-VPN-IPSec-Shrew-avec-Routeur-VPN > [29] > > > > > > > Links: > ------ > [4] http://192.168.1.83:500 > [5] http://206.248.160.8:500 > [6] http://192.168.1.83:500 > [7] http://206.248.160.8:500 > [8] http://fvs_remote.com > [9] http://fvs_local.com > [10] http://fvs_remote.com > [11] http://fvs_local.com > [12] http://fvs_remote.com > [13] > http://blog.igut.fr/post/2009/02/07/Client-VPN-IPSec-Shrew-avec-Routeur-VPN > [14] http://lists.shrew.net/mailman/listinfo/vpn-help > [15] http://lists.shrew.net/mailman/listinfo/vpn-help > [16] > http://blog.igut.fr/post/2009/02/07/Client-VPN-IPSec-Shrew-avec-Routeur-VPN > [17] http://192.168.1.83:500 > [18] http://206.248.160.8:500 > [19] http://192.168.1.83:500 > [20] http://206.248.160.8:500 > [21] http://fvs_remote.com > [22] http://fvs_local.com > [23] http://fvs_remote.com > [24] http://fvs_local.com > [25] http://fvs_remote.com > [26] > http://blog.igut.fr/post/2009/02/07/Client-VPN-IPSec-Shrew-avec-Routeur-VPN > [27] http://lists.shrew.net/mailman/listinfo/vpn-help > [28] http://lists.shrew.net/mailman/listinfo/vpn-help > [29] > http://blog.igut.fr/post/2009/02/07/Client-VPN-IPSec-Shrew-avec-Routeur-VPN > > _______________________________________________ vpn-help mailing list [email protected] http://lists.shrew.net/mailman/listinfo/vpn-help
