So I finally got some time to work on this again and we found the problem it appears to be was the destination match, needed to switch to any/any matching instead. It would appear that destination address and next-hop don't mean the same thing, the actual destination needs to match the destination address, not the next hop.
So, referencing the any/any special case section on http://www.juniper.net/techpubs/en_US/junos10.4/topics/usage-guidelines/services-configuring-ipsec-rules.html#id-12180015 I removed my destination match and vwalla, I can ping across appropriately now using BGP learned routes. Alex, Thanks for the help on just getting the stuff going with next-hop style and the VRF, I really appreciate that. -SH On 12/18/13, 4:55 AM, Alex Arseniev wrote: > And what happens if You ping a destination IP known via BGP across the > tunnel but with different src.ip? > > ping routing-instance VRFname <dst.ip> source <whatever> > > This src.ip must be known by/reachable from far end. > HTH > Thanks > Alex > > On 17/12/2013 20:40, Scott Harvanek wrote: >> BGP is running in the tunnel and the next hop is the far side of the >> tunnel, everything looks correct. All the routes show the far end of >> the tunnel and BGP is established inside the VRF but traffic will not >> pass except of traffic directly between the two endpoints. E.g. >> BGP/ICMP on the tunnel subnet. I'm at a loss. >> >> I'll pull some info and post it back, maybe someone sees something I >> don't. >> >> Scott H. >> >> On 12/17/13, 12:27 PM, Alex Arseniev wrote: >>> For the traffic to be encrypted, the BGP nexthop has to point into >>> the tunnel which means one of the below: >>> 1/ BGP has to run inside the tunnel, or >>> 2/ You have to have a BGP import policy to change the nexthop to >>> tunnel's remote address. If this is eBGP, then also add >>> "accept-remote-nexthop" knob. >>> HTH >>> Thanks >>> Alex >>> >>> On 17/12/2013 16:08, Scott Harvanek wrote: >>>> So this works to establish the tunnels, the problem is, BGP >>>> received routes over the tunnel do not function correctly. The >>>> routes are properly installed in the VRF but traffic to those >>>> destinations does not pass correctly. Does anyone have any >>>> experience running BGP like this on the m-series or does it just >>>> not work on next-hop-style? >>>> >>>> Thanks, >>>> -SH >>>> >>>> On 11/12/13, 1:34 PM, Scott Harvanek wrote: >>>>> Yep excellent, I'll give it a whirl, thanks! >>>>> >>>>> Scott H. >>>>> >>>>> On 11/12/13, 1:24 PM, Alex Arseniev wrote: >>>>>> So, if I understand Your requirement, You want sp-0/0/0.<unit> in >>>>>> VRF, correct? >>>>>> And outgoing GE interface in inet.0? >>>>>> And where the decrypted packets should be placed, inet.0 or VRF? >>>>>> And where from the to-be-ecrypted packets should arrive, from >>>>>> inet.0 or VRF? >>>>>> If the answer is "correct/inet.0/VRF/VRF" then migrate to >>>>>> next-hop-style IPSec and place inside sp-* unit into the VRF >>>>>> leaving outside sp-* unit in inet.0. >>>>>> HTH >>>>>> Thanks >>>>>> Alex >>>>>> >>>>>> On 12/11/2013 16:35, Scott Harvanek wrote: >>>>>>> Alex, >>>>>>> >>>>>>> Yea, tried this but it looks like you can't set it to the >>>>>>> default inet.0 instance, only to things different... the local >>>>>>> gw in my case is in the default instance and I want the service >>>>>>> interface in another so unless I'm mistaken it's in default by >>>>>>> default and this fails? >>>>>>> >>>>>>> Scott H. >>>>>>> >>>>>>> On 11/12/13, 11:22 AM, Alex Arseniev wrote: >>>>>>>> Yes >>>>>>>> >>>>>>>> [edit] >>>>>>>> aarseniev@m120# set services service-set SS1 ipsec-vpn-options >>>>>>>> local-gateway ? >>>>>>>> Possible completions: >>>>>>>> <address> Local gateway address >>>>>>>> routing-instance Name of routing instance that hosts >>>>>>>> local gateway <=====!!!! CHECK THIS OUT!!! >>>>>>>> aarseniev@m120> show version >>>>>>>> Hostname: m120 >>>>>>>> Model: m120 >>>>>>>> JUNOS Base OS boot [10.4S7.1] >>>>>>>> >>>>>>>> HTH >>>>>>>> Thanks >>>>>>>> Alex >>>>>>>> >>>>>>>> On 12/11/2013 16:05, Scott Harvanek wrote: >>>>>>>>> Anyone with any ideas on this? >>>>>>>>> >>>>>>>>> Scott H. >>>>>>>>> >>>>>>>>> On 11/9/13, 12:58 PM, Scott Harvanek wrote: >>>>>>>>>> Is there a way to build a IPSec tunnel / service interface >>>>>>>>>> where the local gateway is NOT in the same routing-instance >>>>>>>>>> as the service interface? >>>>>>>>>> >>>>>>>>>> Here's what I'm trying to do; >>>>>>>>>> >>>>>>>>>> [ router A (SRX) ] == Switch / IS-IS mesh == [ router B m10i ] >>>>>>>>>> [ st0.0 / VRF ] ================= [ sp-0/0/0.0 / VRF ] >>>>>>>>>> >>>>>>>>>> The problem is, I want sp-0/0/0.0 on router B in a VRF but >>>>>>>>>> NOT the outside interface on router B, I cannot commit unless >>>>>>>>>> the outside/local-gateway on the IPSec tunnel is in the same >>>>>>>>>> routing-instance as the service interface, is there a way >>>>>>>>>> around this? The SRX devices can do this without issue. >>>>>>>>>> >>>>>>>>>> service-set XXXX { >>>>>>>>>> interface-service { >>>>>>>>>> service-interface sp-0/0/0.0; <-- want this in a VRF >>>>>>>>>> } >>>>>>>>>> ipsec-vpn-options { >>>>>>>>>> local-gateway x.x.x.x; <-- default routing instance >>>>>>>>>> } >>>>>>>>>> ipsec-vpn-rules XXXX >>>>>>>>>> } >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> juniper-nsp mailing list [email protected] >>>>>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> juniper-nsp mailing list [email protected] >>>>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>>>>> >>>>>>> _______________________________________________ >>>>>>> juniper-nsp mailing list [email protected] >>>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>>>> >>>>>> _______________________________________________ >>>>>> juniper-nsp mailing list [email protected] >>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>>> >>>> >>>> _______________________________________________ >>>> juniper-nsp mailing list [email protected] >>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>> >> > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
