|
In the scenario described by this article, a provider (SP) resides in a Datacenter and a VPN tunnel is initiated to the provider’s device to enable reachability from client network to the SP network. However, the client did not have control of the SP side and therefore could not make changes on the SP side.
Downtime was experienced, and investigation revealed it was caused by a default route announced/injected to the client network over the VPN tunnel from the SP, which thereby forced all traffic to be routed over the VPN tunnel and cause outage.
The following is what the client tunnel configuration looked like:
config vpn ipsec phase1-interface
edit "test-vpn"
set interface "port1"
set peertype any
set type static <<<<<< this is the default setting BTW.
set net-device disable
set mode-cfg enable <<<<<<<<<<<<<
set proposal aes128-sha512
set dhgrp 2
set remote-gw x.x.x.x
end
How the above configuration caused this issue when the tunnel is of type 'STATIC':
There are 2 reasons:
- Because 'mode-cfg' was enabled on the client tunnel, it will request INTERNAL SUBNETS from the server (mode-cfg server) despite how the configuration is a static tunnel. The subnet is reachable over this tunnel.
- On the 'mode-cfg' server, 'ipv4-split-include' is not defined. As such, IKE sees it as a FULL tunnel. The following IKE log shows 'mode-cfg missing INTERNAL_IP4_SUBNET', which means the IKE is set to ALL.
ike 136: test-vpn:1793: mode-cfg missing INTERNAL_IP4_SUBNET: set to ALL
ike 136: test-vpn: mode-cfg add x.x.x.x/255.255.255.255 to ‘test-vpn’/1691
ike 136: test-vpn:0: add route 0.0.0.0/0.0.0.0 gw y.y.y.y oif test-vpn(1691) metric 15 priority 1
What can be done to avoid this issue.
There are multiple ways to prevent this.
- If control or permissions are not available to make changes on the server side, define a higher distance for the default route injected by IKE over the tunnel on the client side.
config vpn ipsec phase1-interface
edit "test-vpn"
set distance 220 <- High enough to prevent this route from knocking off iBGP/any protocol.
end
- Configure 'ipv4-split-include' on the server side (if access to the server is available) to state subnet(s) that can be announced to the other side over this tunnel.
Alternatively, use 'ipv4-split-exclude' on the server to inform it not to announce the subnet(s) to the VPN peer over this tunnel.
|
