Junos OS

Hello,

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

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

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
------------------------------

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.

Hello,

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

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

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
------------------------------

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:

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

Original Message:
Sent: 02-28-2024 09:28
From: MICHAEL DEAN
Subject: Dual ISP IPsec behaviour

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.

Hello,

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

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

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
------------------------------

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?

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:

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

Original Message:
Sent: 02-28-2024 09:28
From: MICHAEL DEAN
Subject: Dual ISP IPsec behaviour

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.

Hello,

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

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

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
------------------------------

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.

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?

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:

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

Original Message:
Sent: 02-28-2024 09:28
From: MICHAEL DEAN
Subject: Dual ISP IPsec behaviour

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.

Hello,

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

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

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
------------------------------

Anyone? Anything?

Tnx.

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.

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?

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:

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

Original Message:
Sent: 02-28-2024 09:28
From: MICHAEL DEAN
Subject: Dual ISP IPsec behaviour

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.

Hello,

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

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

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
------------------------------

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..

Anyone? Anything?

Tnx.

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.

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?

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:

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

Original Message:
Sent: 02-28-2024 09:28
From: MICHAEL DEAN
Subject: Dual ISP IPsec behaviour

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.

Hello,

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

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

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
------------------------------

Hello,

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

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

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.