Junos OS

 View Only
last person joined: 7 days ago 

Ask questions and share experiences about Junos OS.
  • 1.  Dual ISP IPsec behaviour

    Posted 02-24-2024 08:03

    Hello,

    I'm posting again, since I'm pretty stuck.

    I have SRX345 HA with dual ISP. Routing is simple:

    set routing-options static route 0.0.0.0/0 next-hop 11.11.11.11
    set routing-options static route 0.0.0.0/0 next-hop 22.22.22.22

    Towards remote offices (srx300) I have ipsec site-to-site setup. Each remote office has one ISP and 2 IPsec tunnels towards 345HA. 345HA has 2 tunnels  towards each office, each of those 2 tunnels per remote office are using different external interfaces (reth1 and reth2).

    Everything works fine for most of remote offices but one.

    Monitoring traffic is showing that this "problematic" remote office sends isakmp phase1 packets to second 345HA isp link (reht2).

    Packet is received on reht2, shown as 'in' on traffic monitor.

    Packet is being sent back out NOT via reth2, the way it came in, but via ISP1 (reth1).

    Meaning, that remote office initiate phase 1 negotiations, and somehow SRX345HA does not return packet the same way it came in (reth2) but for some reason it uses currently preferred default route for 0/0 which in this case is reth1 interface (ISP1).

    This would make sense if that is the default behavior for ALL other remote offices, but it isn't. Every other remote office creates ipsec s2s as expected, meaning it sends phase1 to SRX345HA reht2 and it gets replied via reth2, hence tunnel goes up.

    Just this for this one 345HA is acting weirdly.

    I've tried making remote office initiator and 345HA as responder, no luck.

    Double checked remote offices configs, one that works correctly and this one that doesn't. No difference besides external and internal IP address.

    I've switched from having static routes bind to st0.x interface for that specific remote office to having traffic initiators in ipsec vpn level, still the same.

    So this remote office can establish successfully ipsec s2s 'tunnel 1' via ISP1 (reth1), but via reth2, no-go.

    I've done traceflow, packet capturing, but no luck.

    Tripple-checked configuration of SRX345HA and remote SRX300: interfaces defined correctly, routing is pretty basic so no potential error there, external-interface on SRX345 side are okay, each ike gateway for single remote office is defined 'ike gw1 = external-interface reth1' and 'ike gw2 = external-interface reth2', st0.x interfaces for each ipsec vpn are correctly bind, I've even created security policies for this remote office allowing any-any. Of course, no luck.

    Any advice?

    Thanks.



    ------------------------------
    Vedran Milicevic
    ------------------------------


  • 2.  RE: Dual ISP IPsec behaviour

    Posted 02-28-2024 11:13

    Vedran,

    What does your default(or full table)outbound routing look like? These are DIAs from providers, just using their IPs on interfaces(ex: no upstream BGP/etc; also part of the first question)? Are you preferring either reth1/2 VPN connection or is it active/active? What route are you using to get back to the "problem" public peer? If you haven't already, maybe put a static host route to the "problem" public peer using reth2 next hop just to test. I might have some more thoughts coming.



    ------------------------------
    MICHAEL D
    ------------------------------



  • 3.  RE: Dual ISP IPsec behaviour

    Posted 02-28-2024 12:37

    Thank you for taking time to read this and even reply.

    What does your default(or full table)outbound routing look like?

    Looks simple that it cant look any simpler thank this:

    set routing-options static route 0.0.0.0/0 next-hop 11.11.11.11
    set routing-options static route 0.0.0.0/0 next-hop 22.22.22.22

    Routing towards vpn endopint is:

    set routing-options static route 192.168.12.0/24 qualified-next-hop st0.1 preference 5
    set routing-options static route 192.168.12.0/24 qualified-next-hop st0.2 preference 10

    About this:  " These are DIAs from providers, just using their IPs on interfaces(ex: no upstream BGP/etc; also part of the first question)? "

    Yes, im just using their IPs on my interfaces in same subnet as my default gw. My reth1 is 11.11.11.10/29 , reth2 is 22.22.22.21/28. No bgp's anything on it.

    Currently I have set up both vpns to be active and routing is taking care of packets back and forth regarding of tunnel state. If st0.1 goes down, then QNH st0.2 take over, and vice versa when st0.1 goes back up. With other remote offices show security ike sa shows both P1 as UP, and show security ipsec sa showing both P2 tunnels UP.

    I did not quite understand this "What route are you using to get back to the "problem" public peer? ", but I think my config routing snippet above could be answer to your question or ...?

    What do you mean here: " If you haven't already, maybe put a static host route to the "problem" public peer using reth2 next hop just to test."

    Are we talking about 345HA and static route to 0/0 or remote office ?

    Once again thank you for your time and your thought, if any more comes up, please spill them all in here.

    Thank you.

    Regards.



    ------------------------------
    Vedran Milicevic
    ------------------------------



  • 4.  RE: Dual ISP IPsec behaviour

    Posted 02-29-2024 09:37

    So, I overlooked the default routes you originally posted, my fault on that. 

    I think I understand how it is working. 

    As far as my test, I wanted to see if pushing specifically pushing traffic back out reth2 for the remote office public endpoint would make a difference. 

    set routing-options static route <ip-of-your-remote-vpn-endpoint>/32 next-hop 22.22.22.22

    This will ensure all traffic to that host leaves on reth2.

    When you look at the routing and forwarding tables, are your defaults both active/load sharing?



    ------------------------------
    MICHAEL D
    ------------------------------



  • 5.  RE: Dual ISP IPsec behaviour

    Posted 03-04-2024 04:15

    Hello,

    It took me a while to get my grip back to this.

    I've done your suggestion. 

    I can confirm that tunnel is now established via reth2.

    However, now reth1 cannot establish tunnel and it's sending all traffic reply via reth2. 

    Now I have reversed "problem" with that static route introduction.

    "Problem" is that both aren't active/load sharing but only one (first), we're talking about 0/0 routes.

    However even with that kind of routing setup, only one being active, I still have 20+ remote offices establishing tunnels to both ISPs on my side (reth1 and reth2).

    Only this one remote office is acting up. Why? Beats me.

    Thank you for sharing your ideas and suggestions.

    Br.



    ------------------------------
    Vedran Milicevic
    ------------------------------



  • 6.  RE: Dual ISP IPsec behaviour

    Posted 26 days ago

    Anyone? Anything?

    Tnx.



    ------------------------------
    Vedran Milicevic
    ------------------------------



  • 7.  RE: Dual ISP IPsec behaviour

    Posted 25 days ago

    Hi,
    For what it's worth,
    I've just spent good part of a workweek on IKEV2 - IKE sa issues on a straight forward site to site VPN. Finally, I have upgraded from 21.4R3-S4.9 to (the latest) 22.4R3.25, problem was solved..



    ------------------------------
    MEINDERT UITMAN
    ------------------------------



  • 8.  RE: Dual ISP IPsec behaviour

    Posted 25 days ago

    Hello,

    thanks for reply.

    Did you have even remotely similar architecture such as mine or?

    What were your issues about?

    Thanks.



    ------------------------------
    Vedran Milicevic
    ------------------------------



  • 9.  RE: Dual ISP IPsec behaviour

    Posted 24 days ago

    Hello Vedran,

    I don't really see a lot of operational output or configuration for troubleshooting this, but the setup seems straight forward, but will be difficult to craft the exact commands.

    Are you using routing-instances? If not, can you show your forwarding table for inet.0? (If you are we'd need the full configuration for the routing-instances).

    show route forwarding-table table default destination broken-remote-vpn-gateway-IP

    show route forwarding-table table default destination working-remote-vpn-gateway-IP

    It will be obvious from the output, but still, it'd be useful to know if loadbalancing is configured

    show configuration | match balance | display set | display inheritance

    What about the flow when the other firewall is making a request to bring up the VPN? (Node 0 is used as an example, but if Node1 is the current master, use that instead)

    show security flow session node 0 source-prefix broken-remote-vpn-gateway

    Speaking of mastership, what is the current status?

    show configuration chassis cluster

    show chassis cluster status

    Anything weird in the KMD logs if you've enabled them (clutching at straws because this is a routing issue)?

    set system syslog file kmd-logs daemon info
    set system syslog file kmd-logs match KMD

    show log kmd-logs

    What's the full configuration of the interfaces on the SRX345HA pair?

    show configuration interfaces | match reth | display set | display inheritance

    show configuration security | match "interface|screen" | display set

    I'm inclined to see the config of the VPNs, BUT it shouldn't really make a difference as we see everything working as expected from a VPN setup point of view so we'll ignore that for now.



    ------------------------------
    ANDREY LEO
    ------------------------------