Le 22/11/2013 20:41, Klaus Groeger a écrit :
In policy based VPN just rely on default route, witch points out the
interface and zone where the VPN's outgoing interface resides. The
packets have to hit the policy between the internal and external zone,
then are injected to the VPN. No additional route is needed.
Hi Klaus,
OK, but does it rely on 0/0 _only_. What I saw appears to be a counter
example, in the context of
internal static route set and external route being a subnetwork of this
internal one. ;-)
Cheers,
mh
Klaus
—
Sent from Mailbox https://www.dropbox.com/mailbox for iPhone
On Thu, Nov 21, 2013 at 4:29 PM, Per Westerlund p...@westerlund.se
mailto:p...@westerlund.se wrote:
Sorry, no automatic route-injection with SRX and policy-based
IPsec VPN. The traffic has to be made to hit the security policy
rules that allows the tunnel traffic, and that is normally manually.
/Per
21 nov 2013 kl. 16:17 skrev Michael Hallgren m.hallg...@free.fr:
Hi,
I ran into the following:
In a pretty much standard setup of a policy-based IPSec VPN
between a
SRX and a cisco ASA, pinging destination behind the SRX worked just
fine from behind the ASA, the other way around didn't. Had few
static
routes set, among them a 0/0 pointing in the direction of the
ASA, and a
10/8 pointing at SRX customers. The host behind the ASA, that I
couldn't
ping was in 10/24, say. Adding a static route 10/24 pointing at
the ASA (not
at the tunnel endpoint), fixed the flow from SRX to ASA.
Was under the impression that policy-based setup is supposed to
handle
static route injection auto-magically. What am I missing?
Cheers,
mh
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
