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

[Geoff Bonallack]

Hi Kevin,

Thanks for the reply.  I'm thinking I'm going to have to implement the route-based VPN - not something I'm familiar with, so I'm guessing it's back to the search engine!  I'm going to try your untrust-untrust suggestion first, just in case I can manage to work it out

Cheers,
Geoff

-----Original Message-----
From: vpn-help-bounces at lists.shrew.net [mailto:vpn-help-bounces at lists.shrew.net] On Behalf Of kevin vpn
Sent: Tuesday, March 15, 2011 9:30 PM
To: vpn-help at lists.shrew.net
Subject: Re: [vpn-help] One policy not passing traffic to NS5GT

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

_______________________________________________
vpn-help mailing list
vpn-help at lists.shrew.net
http://lists.shrew.net/mailman/listinfo/vpn-help