On 11/20/2010 10:09 AM, [email protected] wrote:
      It probably does but it has no way of knowing who to pass the packet to 
as it came back on the wrong port. It has nothing to
match on. There is no way for it to know that the reply it receives on port 500 
corresponds to the request that was sent out on
port 26891.


I think what Alexis was suggesting is that the NAT device ( the one NATing the client traffic to port 26891 ) may have a VPN passthru feature that could be enabled. In this case, it will typically try to keep the port non-translated. VPN passthru is a evil feature that tends to cause more problems than it solves. But in your case, it may be worth a try. Another thing you could try is to port forward UDP port 500 to the internal IP address that the client runs on.

But make no mistake, the VPN gateway should be responding to port 26891. Have you tried updating the firmware on you Netgear gateway?

-Matthew

-----------------------------------~~~~~~~-----------------------------
Doing what you love is Freedom.  | o   o | Kevin Pickard
Loving what you do is Happiness. |   ^   |  [email protected]
------------------------------^^^-----------^^^------------------------


On Sat 10/11/20 10:59 AM , Alexis La Goutte [email protected] sent:
Hi,

No VPN pass through in your router ?
On Sat, Nov 20, 2010 at 4:54 PM,   wrote:
     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. |   ^   |

------------------------------^^^-----------^^^------------------------
On Sat 10/11/20 10:42 AM , Alexis La Goutte  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: MAILFILTERGATEWAY WARNING:
NUMERICAL LINKS ARE OFTEN MALICIOUS: 192.168.1.83:500 [4] [4] [5] ->
MAILFILTERGATEWAY WARNING: NUMERICAL LINKS ARE OFTEN MALICIOUS:
MAILFILTERGATEWAY WARNING: NUMERICAL LINKS ARE OFTEN MALICIOUS:
206.248.160.8:500 [5] [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: MAILFILTERGATEWAY
WARNING: NUMERICAL LINKS ARE OFTEN MALICIOUS: 192.168.1.83:500 [6] [6]
[7] ->
MAILFILTERGATEWAY WARNING: NUMERICAL LINKS ARE OFTEN MALICIOUS:
MAILFILTERGATEWAY WARNING: NUMERICAL LINKS ARE OFTEN MALICIOUS:
206.248.160.8:500 [7] [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] [8] [11] [4]
[1]
and
fvs_local.com [9] [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] [10] [13] [6] [4] and fvs_local.com [11]
[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] [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]
[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]
[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]
[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]
[16]
[19]
[12]
[12]
-NETGEAR[15]


Links:
------
[5] MAILFILTERGATEWAY WARNING: NUMERICAL LINKS ARE OFTEN
MALICIOUS: http://192.168.1.83:500 [17] [17]
[6] MAILFILTERGATEWAY WARNING: NUMERICAL LINKS ARE OFTEN
MALICIOUS: http://206.248.160.8:500 [18] [18]
[7] MAILFILTERGATEWAY WARNING: NUMERICAL LINKS ARE OFTEN
MALICIOUS: http://192.168.1.83:500 [19] [19]
[8] MAILFILTERGATEWAY WARNING: NUMERICAL LINKS ARE OFTEN
MALICIOUS: http://206.248.160.8:500 [20] [20]
[11] http://fvs_remote.com [21] [21]
[12] http://fvs_local.com [22] [22]
[13] http://fvs_remote.com [23] [23]
[14] http://fvs_local.com [24] [24]
[15] http://fvs_remote.com [25] [25]
[16]


http://blog.igut.fr/post/2009/02/07/Client-VPN-IPSec-Shrew-avec-Routeur-VPN
[26]
[26]
[17] http://lists.shrew.net/mailman/listinfo/vpn-help [27] [27]
[18] http://lists.shrew.net/mailman/listinfo/vpn-help [28] [28]
[19]


http://blog.igut.fr/post/2009/02/07/Client-VPN-IPSec-Shrew-avec-Routeur-VPN
[29]
[29]




Links:
------
[4] MAILFILTERGATEWAY WARNING: NUMERICAL LINKS ARE OFTEN
MALICIOUS: http://192.168.1.83:500 [30]
[5] MAILFILTERGATEWAY WARNING: NUMERICAL LINKS ARE OFTEN
MALICIOUS: http://206.248.160.8:500 [31]
[6] MAILFILTERGATEWAY WARNING: NUMERICAL LINKS ARE OFTEN
MALICIOUS: http://192.168.1.83:500 [32]
[7] MAILFILTERGATEWAY WARNING: NUMERICAL LINKS ARE OFTEN
MALICIOUS: http://206.248.160.8:500 [33]
[8] http://fvs_remote.com [34]
[9] http://fvs_local.com [35]
[10] http://fvs_remote.com [36]
[11] http://fvs_local.com [37]
[12] http://fvs_remote.com [38]
[13]

http://blog.igut.fr/post/2009/02/07/Client-VPN-IPSec-Shrew-avec-Routeur-VPN
[39]
[14] http://lists.shrew.net/mailman/listinfo/vpn-help [40]
[15] http://lists.shrew.net/mailman/listinfo/vpn-help [41]
[16]

http://blog.igut.fr/post/2009/02/07/Client-VPN-IPSec-Shrew-avec-Routeur-VPN
[42]
[17] MAILFILTERGATEWAY WARNING: NUMERICAL LINKS ARE OFTEN
MALICIOUS: http://192.168.1.83:500 [43]
[18] MAILFILTERGATEWAY WARNING: NUMERICAL LINKS ARE OFTEN
MALICIOUS: http://206.248.160.8:500 [44]
[19] MAILFILTERGATEWAY WARNING: NUMERICAL LINKS ARE OFTEN
MALICIOUS: http://192.168.1.83:500 [45]
[20] MAILFILTERGATEWAY WARNING: NUMERICAL LINKS ARE OFTEN
MALICIOUS: http://206.248.160.8:500 [46]
[21] http://fvs_remote.com [47]
[22] http://fvs_local.com [48]
[23] http://fvs_remote.com [49]
[24] http://fvs_local.com [50]
[25] http://fvs_remote.com [51]
[26]

http://blog.igut.fr/post/2009/02/07/Client-VPN-IPSec-Shrew-avec-Routeur-VPN
[52]
[27] http://lists.shrew.net/mailman/listinfo/vpn-help [53]
[28] http://lists.shrew.net/mailman/listinfo/vpn-help [54]
[29]

http://blog.igut.fr/post/2009/02/07/Client-VPN-IPSec-Shrew-avec-Routeur-VPN
[55]




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
[30] http://192.168.1.83:500
[31] http://206.248.160.8:500
[32] http://192.168.1.83:500
[33] http://206.248.160.8:500
[34] http://fvs_remote.com
[35] http://fvs_local.com
[36] http://fvs_remote.com
[37] http://fvs_local.com
[38] http://fvs_remote.com
[39]
http://blog.igut.fr/post/2009/02/07/Client-VPN-IPSec-Shrew-avec-Routeur-VPN
[40] http://lists.shrew.net/mailman/listinfo/vpn-help
[41] http://lists.shrew.net/mailman/listinfo/vpn-help
[42]
http://blog.igut.fr/post/2009/02/07/Client-VPN-IPSec-Shrew-avec-Routeur-VPN
[43] http://192.168.1.83:500
[44] http://206.248.160.8:500
[45] http://192.168.1.83:500
[46] http://206.248.160.8:500
[47] http://fvs_remote.com
[48] http://fvs_local.com
[49] http://fvs_remote.com
[50] http://fvs_local.com
[51] http://fvs_remote.com
[52]
http://blog.igut.fr/post/2009/02/07/Client-VPN-IPSec-Shrew-avec-Routeur-VPN
[53] http://lists.shrew.net/mailman/listinfo/vpn-help
[54] http://lists.shrew.net/mailman/listinfo/vpn-help
[55]
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

_______________________________________________
vpn-help mailing list
[email protected]
http://lists.shrew.net/mailman/listinfo/vpn-help

Reply via email to