[vpn-help] One policy not passing traffic to NS5GT

[kevin vpn]

Hi Geoff,

This is a tricky configuration.  I would try one of two options:

1. Make your policy for (2) something like this: Untrust->Untrust, src
<ip pool of vpn clients>, dst 192.168.22/24, service any, action
permit.  Also ensure that in your zone configuration you allow
Intra-zone traffic.  I'm not sure on the zones, try Trust->Untrust too
if that doesn't work.

2. Convert both VPNs (dial-up and site-to-site) to route-based VPNs.
The Dial-up VPN object is sometimes tricky to play with, but when using
route-based VPNs, the VPN clients can be treated in policy just like
any other IP address.


On Tue, 15 Mar 2011 16:05:33 -0400
Geoff Bonallack <gb at stgroup.com> wrote:

> Hi Clemens,
> 
> Ok, that make sense; I was thinking that the tracert should at least
> identify the NS as the first hop, but what you're saying is that the
> NS needs to reply for tracert to do that, right?
> 
> So I then realised that I need to create a policy from Untrust to
> Untrust (i.e. Dialup-VPN to "other" office), but that results in an
> error: "Dialup-VPN must use IPSEC or L2TP in policy."
> 
> Am I going in the wrong direction?
> Cheers,
> Geoff
> 
> From: C.Hoffmann at ProSeS.de [mailto:C.Hoffmann at ProSeS.de]
> Sent: Tuesday, March 15, 2011 1:23 PM
> To: Geoff Bonallack
> Subject: RE: One policy not passing traffic to NS5GT
> 
> Hi Geoff,
> 
> If the Netscreen is configured to drop traffic, there will be no
> answer at all. I assume you made sure you can use the "other" office
> from the NS site. Then I assume it is a routing issue. Did you use a
> VPN IP Pool different from LAN?
> 
> Clemens
> 
> From: vpn-help-bounces at lists.shrew.net
> [mailto:vpn-help-bounces at lists.shrew.net] On Behalf Of Geoff
> Bonallack Sent: Monday, March 14, 2011 10:01 PM To:
> vpn-help at lists.shrew.net Subject: [vpn-help] One policy not passing
> traffic to NS5GT
> 
> Hi folks,
> 
> I've hooked the client (version 2.2.0) up to our Juniper NS5GT, and
> it's working beautifully  - except that one of my two policies isn't
> passing traffic.
> 
> The NS5 is connected to two locations:
> 1. Our office LAN, 192.168.168/24 - I can ping from the client to
> machines in this network 2. To another Juniper at another office (via
> a tunnel), which has a LAN which looks like 192.168.22/24 - this is
> the one that fails
> 
> My policy for (2) above is: from Untrust To Trust, 192.168.22.0/24,
> ANY.
> 
> I was thinking it was a policy problem at the Juniper end, but I'm
> confused by the output of tracert.  For (1) above, it is: 1   431
> ms   479 ms   519 ms  a.b.c.d.juniper.ip [a.b.c.d] 2   527 ms   465
> ms   407 ms  mymachine.network.A.local [192.168.168.5] ...which looks
> correct.
> 
> For (2), it is:
> 
> Tracing route to mymachine.networkB.local [192.168.22.8]
> over a maximum of 10 hops:
> 
>   1     *        *        *     Request timed out.
>   2     *        *        *     Request timed out.
> (and so on, until the max hops are reached).
> 
> My Shrew client has policies of
> 192.168.22.0/255.255.255.0/INCLUDE
> 192.168.168.0/255.255.255.0/INCLUDE
> 
> So my first question is, if the client policy is set right, shouldn't
> it be hitting the Juniper as the first hop, even if the rest of it
> fails? Thanks, Geoff