[strongSwan] VTI device and strongswan ikev2 issue
Miroslav Hostinsky
bman at tls.sk
Wed Nov 22 18:49:52 CET 2017
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
--
Miroslav Hostinsky
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: charon_debug.log
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171122/20f5fb4c/attachment-0002.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ip-address-show.txt
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171122/20f5fb4c/attachment-0006.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ipsec.conf
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171122/20f5fb4c/attachment-0003.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipsec-notify.sh.txt
Type: text/x-shellscript
Size: 611 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171122/20f5fb4c/attachment-0001.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: iptables-save.txt
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171122/20f5fb4c/attachment-0007.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ip-tunnel-show.txt
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171122/20f5fb4c/attachment-0008.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: routing-table.txt
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171122/20f5fb4c/attachment-0009.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: strongswan-statusall.txt
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171122/20f5fb4c/attachment-0010.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xfrm-policy.txt
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171122/20f5fb4c/attachment-0011.txt>
More information about the Users
mailing list