[strongSwan] VTI device and strongswan ikev2 issue

[Noel Kuntze]

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
>>>   rightid=@mailer.mailer.sk
>>>   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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171122/12ceafc8/attachment.sig>