[vpn-help] Netgear FVS318

Matthew Grooms mgrooms at shrew.net
Mon Nov 22 16:55:49 CST 2010


On 11/20/2010 10:09 AM, kpickard at simplyc.com 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. |   ^   |  kpickard at simplyc.com
> ------------------------------^^^-----------^^^------------------------
>
>
> On Sat 10/11/20 10:59 AM , Alexis La Goutte alexis.lagoutte at gmail.com 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
> vpn-help at lists.shrew.net
> http://lists.shrew.net/mailman/listinfo/vpn-help




More information about the vpn-help mailing list