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 "". 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:
Encryption domain:
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
