I have compiled and configured such routed-based IPSec. I must say that it is non-standard solution. I have not found a similar in WWW. But I want to know your opinion about this.
here my goal is:
- To separate the routing and ipsec with different routing-instances. Here routing-instance INET.inet.0 does not know any about network 18.104.22.168/24.
-Link physically connect to INET , vpn interface st0.0 belongs to Gn routing-instance. Gn.inet.0 has route to 22.214.171.124/24( direct).
ICMP packets from source 126.96.36.199 to destination 188.8.131.52 sent and recieved successfully.
Show security ike/ipsec security-associatons outputs say that ike and ipsec is UP.
My question: is scheme correct from the point of view of common sense ?
This is a good solution to getting routing separation for a vpn connected subnet. this allows the vpn subnet to have a default route for all traffic up the vpn tunnel or even be an isolated segment with limited routing available outside the network.
You'll find the same basic setup in the Day One: Juniper Ambassadors Cookbook for the Enterprise Recipe 5.
Thank you very much! Not the first time helping me!
Steve, hello! can i use this scheme with gre interface. ( no ipsec). Only GRE. routing and tunnel separated ?
Yes, the same concept can apply to any tunnel connection.
See KB24592 for the gre example.
Recipe 5 has the VPN tunnel setup for routing in inet.0. How can this be setup in a VR? In other words, have a VR for tunnel setup with the resulting st0 interface in another VR.
I wan't to do this to segregate management traffic in inet.0 from everything else.
Thanks in advance
The only changes you would need to make to the setup would be those for the ISP and associated interface.
This will isolate the ISP and gateway interface into their own vr and routing table as well.
Thanks for the reply. That's what I have setup, st0.x IFL shows up but don't have connectivity across. policies are wide open at this point and all host-inbound allowed.
Check the ike and vpn status to confirm the tunnel has come up first.
If the vpn is up, check the route into the tunnel is active for the vpn traffic
show route table vrname.inet.0
And look for sessions created for the traffic.
show security flow session source-prefix 192.168.1.20