Hi, 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, 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.
Kind regards Noel On 22.11.2017 18:49, Miroslav Hostinsky wrote: > Hello Noel, > > 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. > > Actually my IPSEC/*swan knowledge is not very good so sorry if my answer are > dumb. > > I am attaching logs/configs as you requested. > > Thank you, > > BR, > Miroslav > > On 2017-11-22 17:41, Noel Kuntze wrote: >> Hello Miroslav, >> >> I suspect that the policy lookup for the received packets fail. Check >> what the source of the packets is that you send over the vti device. >> Anyway, please provide the full list of information from the >> HelpRequests[1] page. >> >> [1] https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests >> >> Kind regards >> >> Noel >> >> On 22.11.2017 16:47, Miroslav Hostinsky wrote: >>> Hello, >>> >>> I have an issue configuring StrongSwan with VTI interface as roadwarrior. >>> This is my configuration: >>> >>> ipsec.conf: >>> >>> config setup >>> >>> conn %default >>> keyexchange=ikev2 >>> ikelifetime=60m >>> keylife=20m >>> rekeymargin=3m >>> rekey=no >>> dpdaction=restart >>> dpddelay=30s >>> compress=yes >>> auto=start >>> >>> conn acnnet >>> leftupdown=/usr/local/sbin/ipsec-notify.sh >>> left=%defaultroute >>> leftauth=eap >>> leftsourceip=%config4,%config6 >>> rightauth=pubkey >>> rightsubnet=0.0.0.0/0,::/0 >>> eap_identity=%identity >>> leftid=bman >>> right=mailer.domena.sk >>> [email protected] >>> mark=28 >>> >>> VTI interface is configured using lefupdown script (real commands executed): >>> >>> ip tunnel add vti1 local 85.105.254.225 remote 185.210.28.63 mode vti key >>> 28 ikey 28 >>> ip link set vti1 up >>> ip addr add 192.168.228.10 dev vti1 >>> ip route add 74.99.179.0/24 dev vti1 >>> sysctl -w net.ipv4.conf.vti1.disable_policy=1 >>> >>> 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. >>> >>> >>> 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): >>> >>> # ip -s tunnel show >>> vti1: ip/ip remote 185.210.28.63 local 85.105.254.225 ttl inherit key 28 >>> RX: Packets Bytes Errors CsumErrs OutOfSeq Mcasts >>> 0 0 805 0 0 0 >>> TX: Packets Bytes Errors DeadLoop NoRoute NoBufs >>> 401 68170 0 0 0 0 >>> ip_vti0: ip/ip remote any local any ttl inherit nopmtudisc key 0 >>> RX: Packets Bytes Errors CsumErrs OutOfSeq Mcasts >>> 0 0 0 0 0 0 >>> TX: Packets Bytes Errors DeadLoop NoRoute NoBufs >>> 0 0 0 0 0 0 >>> >>> It seems that, RX Errors on vti1 are currently missing ICMP echo reply >>> packets. But is counted as RX errors, not RX received packets. >>> >>> Do you have any idea what's wrong? >>> >>> 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). >>> >>> Route installation is disabled in charon.conf. >>> >>> Normal connection using Virtual IP is working great. >>> >>> >>> Thank you very much for any help. >>> >>> >>> BR, >>> >>> Miroslav >
signature.asc
Description: OpenPGP digital signature
