In this scenario, the FortiClient IPsec VPN tunnel is established correctly and traffic generated from the Ubuntu host is routed through the VPN.
However, traffic generated from Docker containers using the default Docker bridge network may use Docker subnets such as 172.17.x.x or 172.18.x.x, and may not match the Linux IPsec/XFRM policy. As a result, the traffic can attempt to leave through the physical interface instead of the IPsec tunnel.
In the examples below, internal-app.example.local and 10.10.20.51 are used as example remote VPN resources.
As a workaround, run the affected container using the host network stack:
docker run -it --rm --network host --name test-ipsec python:3.8.10-buster bash
The key option is:
--network host
This option allows the Docker container to use the same network stack as the Ubuntu host.
After the container starts, validate connectivity to the example remote resource:
ping internal-app.example.local
Or:
ping 10.10.20.51
To identify the physical interface used by the Ubuntu host to reach the remote VPN resource, run:
ip route get 10.10.20.51
To verify that the traffic is sent through the IPsec tunnel, run the following command on the Ubuntu host. Replace <host_physical_interface> with the interface shown in the previous command output:
sudo tcpdump -ni <host_physical_interface> host 10.10.20.51
Using the --network host option allows the container to share the Ubuntu host network stack and reach the example remote resource through the FortiClient IPsec VPN.
| 
