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 <[email protected]> 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: [email protected] [mailto:[email protected]] > 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: [email protected] > [mailto:[email protected]] On Behalf Of Geoff > Bonallack Sent: Monday, March 14, 2011 10:01 PM To: > [email protected] 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 [email protected] http://lists.shrew.net/mailman/listinfo/vpn-help
