openSwan VPN работает, не удается проверить связь с удаленной подсетью

Когда я запускаю команду ipsec auto status, я получаю следующий вывод:

......           
172.16.255.1/32===104.131.13.155<104.131.13.155>:17/1701...41.203.65.124<41.203.    65.124>===10.100.108.51/32; erouted; eroute owner: #13
.......
000 #13: "globacom-vpn":500 STATE_QUICK_I2 (sent QI2, IPsec SA established);     EVENT_SA_REPLACE in 2243s; newest IPSEC; eroute owner; isakmp#10; idle; import:admin initiate
000 #13: "globacom-vpn" esp.e5adc724@41.203.65.124 esp.7b33a369@104.131.13.155 tun.0@41.203.65.124 tun.0@104.131.13.155 ref=0 refhim=4294901761
000 #10: "globacom-vpn":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 79407s; newest ISAKMP; lastdpd=10s(seq in:15699 out:0); idle; import:admin initiate
000

статус службы ipsec

IPsec running  - pluto pid: 14150
pluto pid 14150
1 tunnels up
some eroutes exist

политика ip xfrm

src 172.16.255.1/32 dst 10.100.108.51/32 proto udp sport 1701
    dir out priority 2080
    tmpl src 104.131.13.155 dst 41.203.65.124
            proto esp reqid 16405 mode tunnel
src 10.100.108.51/32 dst 172.16.255.1/32 proto udp dport 1701
    dir fwd priority 2080
    tmpl src 41.203.65.124 dst 104.131.13.155
            proto esp reqid 16405 mode tunnel
src 10.100.108.51/32 dst 172.16.255.1/32 proto udp dport 1701
    dir in priority 2080
    tmpl src 41.203.65.124 dst 104.131.13.155
            proto esp reqid 16405 mode tunnel
src ::/0 dst ::/0
    socket out priority 0
src ::/0 dst ::/0
    socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket out priority 0

пинг 10.100.108.51

PING 10.100.108.51 (10.100.108.51) 56(84) bytes of data.
From 104.131.13.155 icmp_seq=1 Destination Host Unreachable
From 104.131.13.155 icmp_seq=2 Destination Host Unreachable
From 104.131.13.155 icmp_seq=3 Destination Host Unreachable

Что я делаю не так?

Наконец исправил эту проблему.

Вот что я сделал:

В файле ipsec.conf мне пришлось закомментировать левый протокол, который был установлен на
```
leftprotoport=17/1701
```
Это существенно ограничивает соединение vpn с L2TP с использованием порта UDP 1701. Проверка политики ip xfrm показывает, что для портов источника и получателя установлено значение 1701. Это означает, что я не мог отправлять трафик через TCP. Единственным разрешенным трафиком был UDP-порт 1701.
Я заметил, что были некоторые ошибки контрольной суммы udp, когда я запускал tcpdump на eth0. Очевидно, это было результатом настройки debian на использование аппаратной разгрузки контрольной суммы TCP / UDP. Следующие команды отключили его.
```
$ ethtool --offload  eth0  rx off  tx off
$ ethtool -K eth0 gso off
```

Теперь, когда я запускаю трассировку к удаленному хосту / сети, я вижу только один переход по сравнению с 11, когда была настроена неправильная политика ipsec. Я также вижу пакеты ESP (spi = 0XXXX, seq = xxxx) как часть вывода tcpdump на удаленный хост при отправке трафика в форме ping / telnet.