>> I have to assume if incoming traffic is received on the one armed concentrator coming from WAN1 of the branch, that the return traffic will be sent to the same tunnel. This is definitely the case. It’s how if traffic originates at the concentrator end it eventually ends up on the ‘correct’ (based on the SD-WAN rules at the spoke) site. Initially traffic initiated at the VPN concentrator end is just placed into one of the two tunnels to the spoke (no logic is applied). The SD-WAN rules are then applied to traffic as it returns from the spoke to the VPN concentrator and it’s put into the ‘correct’ tunnel. Then when the traffic is received at the VPN concentrator it then know the tunnel to use based on the rules applied by the spoke. >> for question number two: this was not based on any documentation. I was able at that time to do a poc for a client with demo MX'es and we simply observed the behavior by using iperf testing and checking the uplink statistics on both MX'es at the same time. I haven’t seen this documented anywhere either, but have heard that the MXs will always try and make the connection to the actual IP address assigned to a WAN interface first. If that fails they’ll then try and use the public IP address (I’ve never done a packet capture to see if this is actually true though). The VPN registry provides both the public address that it sees, and the IP address assigned to the WAN interface to the peer MXs (the MXs themselves send their Interface IP address to the VPN registry as part of the registration process).
... View more
