<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hello,<div class=""><br class=""></div><div class="">I am not sure if I understand you, but source IP of the outgoing packets on vti1 are right for me (it was always 95.115.254.161).</div><div class=""><br class=""></div><div class=""><div class=""><font face="Courier New" class=""># ip a s vti1</font></div><div class=""><font face="Courier New" class="">5: vti1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN qlen 1</font></div><div class=""><font face="Courier New" class=""> link/ipip 10.198.54.208 peer 95.115.254.165</font></div><div class=""><font face="Courier New" class=""> inet 95.115.254.161/32 scope global vti1</font></div><div class=""><font face="Courier New" class=""> valid_lft forever preferred_lft forever</font></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">current ipv4 routing table is following (I simplified my configuration, removed second physical interface, removed default route):</div><div class=""><br class=""></div><div class=""><div class=""><font face="Courier New" class=""># ip -4 r s table all</font></div><div class=""><font face="Courier New" class="">8.8.8.8 via 10.198.54.1 dev eth0</font></div><div class=""><font face="Courier New" class="">10.198.54.0/24 dev eth0 proto kernel scope link src 10.198.54.208 metric 100</font></div><div class=""><font face="Courier New" class="">95.115.254.165 via 10.198.54.1 dev eth0</font></div><div class=""><font face="Courier New" class="">195.210.28.0/24 dev vti1 scope link</font></div><div class=""><font face="Courier New" class="">broadcast 10.198.54.0 dev eth0 table local proto kernel scope link src 10.198.54.208</font></div><div class=""><font face="Courier New" class="">local 10.198.54.208 dev eth0 table local proto kernel scope host src 10.198.54.208</font></div><div class=""><font face="Courier New" class="">broadcast 10.198.54.255 dev eth0 table local proto kernel scope link src 10.198.54.208</font></div><div class=""><font face="Courier New" class="">local 95.115.254.161 dev vti1 table local proto kernel scope host src 95.115.254.161</font></div><div class=""><font face="Courier New" class="">broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1</font></div><div class=""><font face="Courier New" class="">local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1</font></div><div class=""><font face="Courier New" class="">local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1</font></div><div class=""><font face="Courier New" class="">broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1</font></div></div><div class=""><br class=""></div><div class="">There is the static route 195.210.28.0/24 via vti1. If I do “ping 195.210.28.63” I can see using tcpdump on vti1 following output:</div><div class=""><br class=""></div><div class=""><div class=""><font face="Courier New" class=""># tcpdump -i vti1 -n</font></div><div class=""><font face="Courier New" class="">tcpdump: verbose output suppressed, use -v or -vv for full protocol decode</font></div><div class=""><font face="Courier New" class="">listening on vti1, link-type RAW (Raw IP), capture size 262144 bytes</font></div><div class=""><font face="Courier New" class="">20:08:07.776307 IP 95.115.254.161 > 195.210.28.63: ICMP echo request, id 1098, seq 480, length 64</font></div><div class=""><font face="Courier New" class="">20:08:08.776218 IP 95.115.254.161 > 195.210.28.63: ICMP echo request, id 1098, seq 481, length 64</font></div><div class=""><font face="Courier New" class="">20:08:09.776228 IP 95.115.254.161 > 195.210.28.63: ICMP echo request, id 1098, seq 482, length 64</font></div><div class=""><font face="Courier New" class="">20:08:10.776196 IP 95.115.254.161 > 195.210.28.63: ICMP echo request, id 1098, seq 483, length 64</font></div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I can see there, that source IP is 95.115.254.161, so right IP address. This flow is running over IKEv2 tunnel.</div><div class=""><br class=""></div><div class="">If I do tcpdump on underlying eth0 device:</div><div class=""><br class=""></div><div class=""><div class=""><font face="Courier New" class=""># tcpdump -i eth0 -n udp</font></div><div class=""><font face="Courier New" class="">tcpdump: verbose output suppressed, use -v or -vv for full protocol decode</font></div><div class=""><font face="Courier New" class="">listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes</font></div><div class=""><font face="Courier New" class="">20:09:31.778294 IP 10.198.54.208.ipsec-nat-t > 95.115.254.165.ipsec-nat-t: UDP-encap: ESP(spi=0xc39fd86f,seq=0x234), length 136</font></div><div class=""><font face="Courier New" class="">20:09:31.792601 IP 95.115.254.165.ipsec-nat-t > 10.198.54.208.ipsec-nat-t: UDP-encap: ESP(spi=0xc69deaf7,seq=0x24c), length 136</font></div><div class=""><font face="Courier New" class="">20:09:32.131698 IP 95.115.254.165.ipsec-nat-t > 10.198.54.208.ipsec-nat-t: UDP-encap: ESP(spi=0xc69deaf7,seq=0x24d), length 104</font></div><div class=""><span style="font-family: "Courier New";" class="">20:09:32.778291 IP 10.198.54.208.ipsec-nat-t > 95.115.254.165.ipsec-nat-t: UDP-encap: ESP(spi=0xc39fd86f,seq=0x235), length 136</span></div><div class=""><font face="Courier New" class="">20:09:32.792787 IP 95.115.254.165.ipsec-nat-t > 10.198.54.208.ipsec-nat-t: UDP-encap: ESP(spi=0xc69deaf7,seq=0x24e), length 136</font></div><div class=""><font face="Courier New" class="">20:09:33.778217 IP 10.198.54.208.ipsec-nat-t > 95.115.254.165.ipsec-nat-t: UDP-encap: ESP(spi=0xc39fd86f,seq=0x236), length 136</font></div><div class=""><font face="Courier New" class="">20:09:33.792943 IP 95.115.254.165.ipsec-nat-t > 10.198.54.208.ipsec-nat-t: UDP-encap: ESP(spi=0xc69deaf7,seq=0x24f), length 136</font></div></div><div class=""><br class=""></div><div class="">I guess that 10.198.54.208->95.115.254.165 is ICMP echo request (which I see on vti1 when doing tcpdump) and 95.115.254.165->10.198.54.208 is ICMP echo reply (this I only guess, but there is no other traffic than this ICMP flow).</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">For reference I am pasting statusall outout:</div><div class=""><br class=""></div><div class=""><div class=""><font face="Courier New" class=""># strongswan statusall</font></div><div class=""><font face="Courier New" class="">Status of IKE charon daemon (strongSwan 5.5.3, Linux 3.10.0-693.5.2.el7.x86_64, x86_64):</font></div><div class=""><font face="Courier New" class=""> uptime: 18 minutes, since Nov 22 19:59:23 2017</font></div><div class=""><font face="Courier New" class=""> malloc: sbrk 2859008, mmap 0, used 562720, free 2296288</font></div><div class=""><font face="Courier New" class=""> worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2</font></div><div class=""><font face="Courier New" class=""> loaded plugins: charon aes des rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints acert pubkey pkcs1 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp curve25519 xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink resolve socket-default farp stroke vici updown eap-identity eap-md5 eap-gtc eap-mschapv2 eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-pam xauth-noauth dhcp unity</font></div><div class=""><font face="Courier New" class="">Listening IP addresses:</font></div><div class=""><font face="Courier New" class=""> 10.198.54.208</font></div><div class=""><font face="Courier New" class=""> 95.115.254.161</font></div><div class=""><font face="Courier New" class="">Connections:</font></div><div class=""><font face="Courier New" class=""> alconet: %any...<a href="http://ipsec.alconet.sk" class="">ipsec.alconet.sk</a> IKEv2, dpddelay=30s</font></div><div class=""><font face="Courier New" class=""> alconet: local: [bmanovic] uses EAP authentication with EAP identity '%any'</font></div><div class=""><font face="Courier New" class=""> alconet: remote: [<a href="http://ipsec.alconet.sk" class="">ipsec.alconet.sk</a>] uses public key authentication</font></div><div class=""><font face="Courier New" class=""> alconet: child: dynamic === 0.0.0.0/0 ::/0 TUNNEL, dpdaction=restart</font></div><div class=""><font face="Courier New" class="">Security Associations (1 up, 0 connecting):</font></div><div class=""><font face="Courier New" class=""> alconet[1]: ESTABLISHED 18 minutes ago, 10.198.54.208[bmanovic]...95.115.254.165[<a href="http://ipsec.alconet.sk" class="">ipsec.alconet.sk</a>]</font></div><div class=""><font face="Courier New" class=""> alconet[1]: IKEv2 SPIs: aac4fe8159ef3f03_i* d183908ac6976b91_r, rekeying disabled</font></div><div class=""><font face="Courier New" class=""> alconet[1]: IKE proposal: AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519</font></div><div class=""><font face="Courier New" class=""> alconet{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c69deaf7_i c39fd86f_o, IPCOMP CPIs: 9858_i 7f79_o</font></div><div class=""><font face="Courier New" class=""> alconet{1}: AES_CBC_128/HMAC_SHA2_256_128, 0 bytes_i, 91560 bytes_o (1090 pkts, 1s ago), rekeying disabled</font></div><div class=""><font face="Courier New" class=""> alconet{1}: 95.115.254.161/32 === 0.0.0.0/0</font></div></div><div class=""><br class=""></div><div class="">As I wrote above, I simplified my configuration, but the result is the same. It doesn't work.</div><div class=""><br class=""></div><div class="">Do you still think, that this is that source IP issue?</div><div class=""><br class=""></div><div class="">Thank you for your help,</div><div class=""><br class=""></div><div class="">BR,</div><div class="">Miroslav</div><div class=""><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">On 22 Nov 2017, at 19:22, Noel Kuntze <<a href="mailto:noel.kuntze+strongswan-users-ml@thermi.consulting" class="">noel.kuntze+strongswan-users-ml@thermi.consulting</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi,<br class=""><br class="">The route over the VTI device does not indicate a preferred source IP, so the kernel takes the one from the default route, which is in term deferred from the route to 10.198.54.0/24,<br class="">which is 10.198.54.208. I'm pretty sure running tcpdump on the VTI device confirms that. So the source IP is wrong, as I wrote before. You need to set the virtual IP as source IP in your updown script.<br class=""><br class="">Kind regards<br class=""><br class="">Noel<br class=""><br class="">On 22.11.2017 18:49, Miroslav Hostinsky wrote:<br class=""><blockquote type="cite" class="">Hello Noel,<br class=""><br class="">I do not know what you exactly mean, but the source IP send over VTI interface is the same as configured on VTI interface (95.115.254.161 in this case). As I wrote, I can see that ICMP echo request & reply are delivered to this IPSEC endpoint machine (but I only suppose, because packets are encrypted when sniffing using tcpdump, but there is no other ICMP traffic). It seems that encrypted echo-reply is delivered to the machine, but "kernel/ipsec stack" is not able to properly "route" to the VTI device.<br class=""><br class="">Actually my IPSEC/*swan knowledge is not very good so sorry if my answer are dumb.<br class=""><br class="">I am attaching logs/configs as you requested.<br class=""><br class="">Thank you,<br class=""><br class="">BR,<br class="">Miroslav<br class=""><br class="">On 2017-11-22 17:41, Noel Kuntze wrote:<br class=""><blockquote type="cite" class="">Hello Miroslav,<br class=""><br class="">I suspect that the policy lookup for the received packets fail. Check<br class="">what the source of the packets is that you send over the vti device.<br class="">Anyway, please provide the full list of information from the<br class="">HelpRequests[1] page.<br class=""><br class="">[1] <a href="https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests" class="">https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests</a><br class=""><br class="">Kind regards<br class=""><br class="">Noel<br class=""><br class="">On 22.11.2017 16:47, Miroslav Hostinsky wrote:<br class=""><blockquote type="cite" class="">Hello,<br class=""><br class="">I have an issue configuring StrongSwan with VTI interface as roadwarrior. This is my configuration:<br class=""><br class="">ipsec.conf:<br class=""><br class="">config setup<br class=""><br class="">conn %default<br class=""> keyexchange=ikev2<br class=""> ikelifetime=60m<br class=""> keylife=20m<br class=""> rekeymargin=3m<br class=""> rekey=no<br class=""> dpdaction=restart<br class=""> dpddelay=30s<br class=""> compress=yes<br class=""> auto=start<br class=""><br class="">conn acnnet<br class=""> leftupdown=/usr/local/sbin/ipsec-notify.sh<br class=""> left=%defaultroute<br class=""> leftauth=eap<br class=""> leftsourceip=%config4,%config6<br class=""> rightauth=pubkey<br class=""> rightsubnet=0.0.0.0/0,::/0<br class=""> eap_identity=%identity<br class=""> leftid=bman<br class=""> right=<a href="http://mailer.domena.sk" class="">mailer.domena.sk</a><br class=""> <a href="mailto:rightid=@mailer.mailer.sk" class="">rightid=@mailer.mailer.sk</a><br class=""> mark=28<br class=""><br class="">VTI interface is configured using lefupdown script (real commands executed):<br class=""><br class="">ip tunnel add vti1 local 85.105.254.225 remote 185.210.28.63 mode vti key 28 ikey 28<br class="">ip link set vti1 up<br class="">ip addr add 192.168.228.10 dev vti1<br class="">ip route add 74.99.179.0/24 dev vti1<br class="">sysctl -w net.ipv4.conf.vti1.disable_policy=1<br class=""><br class="">It seems that outgoing connection via vti1 interface is working (outgoing ICMP echo request to subnet 74.99.179.0/24 ). But I am unable to receive ICMP echo reply. Using tcpdump I can clearly see, that IPSEC encrypted ICMP echo reply is returning via physical interface, but not via vti1.<br class=""><br class=""><br class="">I found, that, TX bytes is correctly counted via vti1, but RX shows errors (it seems that each ICMP echo reply packet is counted as +1 error):<br class=""><br class=""># ip -s tunnel show<br class="">vti1: ip/ip remote 185.210.28.63 local 85.105.254.225 ttl inherit key 28<br class="">RX: Packets Bytes Errors CsumErrs OutOfSeq Mcasts<br class=""> 0 0 805 0 0 0<br class="">TX: Packets Bytes Errors DeadLoop NoRoute NoBufs<br class=""> 401 68170 0 0 0 0<br class="">ip_vti0: ip/ip remote any local any ttl inherit nopmtudisc key 0<br class="">RX: Packets Bytes Errors CsumErrs OutOfSeq Mcasts<br class=""> 0 0 0 0 0 0<br class="">TX: Packets Bytes Errors DeadLoop NoRoute NoBufs<br class=""> 0 0 0 0 0 0<br class=""><br class="">It seems that, RX Errors on vti1 are currently missing ICMP echo reply packets. But is counted as RX errors, not RX received packets.<br class=""><br class="">Do you have any idea what's wrong?<br class=""><br class="">I am using Centos 7.4 with strongswan-5.5.3-1.el7.x86_64 from EPEL. A tried with same result on Archlinux (kernel 4.9 and strongswan 5.6.0).<br class=""><br class="">Route installation is disabled in charon.conf.<br class=""><br class="">Normal connection using Virtual IP is working great.<br class=""><br class=""><br class="">Thank you very much for any help.<br class=""><br class=""><br class="">BR,<br class=""><br class="">Miroslav<br class=""></blockquote></blockquote><br class=""></blockquote><br class=""></div></div></blockquote></div><br class=""></div></body></html>