Site-2-Site w/ Routing with "To center, or through the center to other satellites, to internet"

[RKinsp]

Hey everyone,

We are looking for confirmation regarding routing behavior in IPSEC Site-to-Site.

For some of our systems, we are using the option to Route "To center, or through the center to other satellites, to internet and other VPN targets". In this case we have a third-party "center" and our gateway is the satellite.

We've noticed that when using this option, we are unable to ping directly attached networks that are not part of any VPN domain. It seems that VPN routing takes over and is trying to send this traffic through the tunnel.

If we validate VPN routing (using ccc, great tool btw), the interface IP (/32) itself is listed as the local gateway encryption domain.

Example, if we have the gateway setup as below, user traffic works, but I cannot ping the LAN GW (172.16.1.69).

Local Gateway

Interfaces:

• LAN - 172.16.1.70 / 28
• WAN - 201.x.x.x

Local Device subnet:

• 10.18.0.0/16

Encryption domain:

• 10.18.0.0/16

Routes:

• 10.18.0.0/16 GW  172.16.1.69
• Default GW 201.x.x.y

Community:

• "To center, or through the center to other satellites, to internet"

CCC Show VPN routing

Local gateway encryption domain:

• 10.18.0.0 - 10.18.255.255
• 172.16.1.70
• 201.x.x.x

We've reached the conclusion that VPN Routing does the following for the Satellite when "To center, or through the center to other satellites, to internet" is selected:

All traffic is routed to Hub/center except:

•  Local encryption Domains.
•  Local interface IPs

Local routes and directly attached subnets are ignored, system will try to encrypt/route to center if not defined as a local encryption domain.

Can anyone else confirm this behavior?

Ideally we would like to find a way for the directly attached networks to ping without having to add it to the local VPN domain, so if anyone knows of a workaround for this, please let me know!

Thanks in advance,

RK

[PhoneBoy]

VPN Routing generally overrides OS-level routing.
Given the goal of this particular option, I'm quite certain it is expected behavior.
Even if those hosts are part of the Encryption Domain, you still (generally) need access rules in place to allow traffic to/from those hosts.