So it sounds like the primary routing for the site would always use ip2 while you want the VPN to override this and use ip1 instead.
So I would setup the routing override using KB above that would setup match criteria for UDP 500 and a destination ip address of the remote gateway/32 to route out ip1.
Using this instead of a static route will only change the routing for the vpn gateway traffic and everything else will continue to use the standard routing table.
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP - Retired)
Original Message:
Sent: 11-15-2024 03:27
From: Cs.Bandita
Subject: Route Conflicts in Site-to-Site VPNs
Sadly, I can't open the site you sent; it says the site is temporarily unavailable. (I'll check it later.)
I'm trying to clarify the issue I'm facing since you mentioned that you're not sure you fully understand the problem:
Most of the time, I don't need to create a static route to the customer network as I mentioned before. This is because, in the IKE gateway configuration, I specify the WAN interface I want to use for the VPN connection. However, in this specific case, I need to create a static route even though I already defined the WAN interface in the IKE gateway configuration, as shown below:
set security ike gateway <ike-gw-name> ike-policy <ike-policy-name>
set security ike gateway <ike-gw-name> address <customer-public-ip>
set security ike gateway <ike-gw-name> external-interface reth0.0
set security ike gateway <ike-gw-name> general-ikeid
set security ike gateway <ike-gw-name> version v1-only
If I don't create a static route to the customer's public IP using the correct WAN interface address, the VPN doesn't establish. We have two WAN interfaces from different ISPs, and they are configured in the routing table like this:
set routing-options static route 0.0.0.0/0 next-hop <our public ip2>
set routing-options static route 0.0.0.0/0 qualified-next-hop <our public ip1> preference 7
set routing-options static route 0.0.0.0/0 preference 5
On this device, I manage more than 50 site-to-site VPNs, and this type of static route is only required for about 8 of them without any clear reason. This kind of static route shouldn't be necessary for a site-to-site VPN to work.
However, because of this static route, the customer cannot reach our public sites, which are hosted on a different WAN interface with a different public IP address. When the communication reaches the other WAN interface, it gets routed back to them on a different interface (reth0.0 which is for the vpns) due to the static route I added.
I see no reason why we need this static route to make the s2s vpn work, and therefore our public pages are not accessible from the client's internal network.
Thank you very much for your help.
------------------------------
ANDRAS CSERNUS
Original Message:
Sent: 11-14-2024 13:01
From: spuluka
Subject: Route Conflicts in Site-to-Site VPNs
I'm not sure I follow the whole issue, but it sounds like you might be able to use the source based routing option for this problem. This will use the criteria of the source address to select the routing path and can also be combined with destination address or port criteria as well.
And example configuration is here.
https://supportportal.juniper.net/s/article/SRX-Source-based-routing-configuration-example?language=en_US
------------------------------
Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP - Retired)
http://puluka.com/home
Original Message:
Sent: 11-14-2024 08:53
From: ANDRAS CSERNUS
Subject: Route Conflicts in Site-to-Site VPNs
Hi all,
I'm managing a site-to-site VPN for one of our clients, and I've run into an unusual routing issue that I'm hoping someone here can help with.
The setup is such that, unlike other clients, this one requires a specific static route to get the VPN connection working. Here's the relevant configuration line:
set routing-options static route <customer public IP> next-hop <our public IP1>
With this static route, the VPN works fine. However, if I remove it, the connection fails.
The problem arises when the client tries to access one of our public-facing websites that's hosted on a different public IP (let's call it our public IP2). Because of the static route above, traffic from this second public IP also gets routed back through the VPN's public IP (our public IP1) rather than following its own path back out on the interface it came from.
I'm looking for a configuration that would let me set a rule so that any requests coming in via public IP2 are routed back out on the same interface, instead of going over the VPN route.
Also, if anyone has an explanation as to why certain VPN connections require a static route for functionality while others with almost identical settings don't, I'd really appreciate it.
Thanks in advance!
------------------------------
ANDRAS CSERNUS
------------------------------