[strongSwan] Issuse with VTI packet forwarding

Thu Nov 30 16:54:26 CET 2017

Hello,

The IPs of the VTI need to correspond to the IPs of the SAs (not the policies).
The exception (0.0.0.0) is described in the wiki article I linked you before.

Kind regards

Noel

On 30.11.2017 02:50, Naveen Neelakanta wrote:
> Hi Noel,
> 
> Thanks i got the VTI working after i change the vti local and remote
> ip to match to the SPD IPs. How ever
> Is it possible to configure VTI interface with different Ip other than
> the policys.
> 
> Working config:
> 
> ip tunnel add ipsec0 local 10.24.18.209 remote 10.24.18.35 mode vti okey 32
> below is my ipsec configuration:
> conn net-net
>         left=10.24.18.209
>         leftsubnet=0.0.0.0/0
>         right=10.24.18.35
>         rightsubnet=0.0.0.0/0
>         ike=aes128-sha1-modp1024
>         esp=null-md5-modp1024
>         auto=add
>         mark_out=32
> 
> Not working when i change the vti interface IPs to the below and
> enable forwarding:
> ip tunnel add ipsec0 local 10.24.18.211 remote 0.0.0.0 mode vti okey 32
> 
> Appreciate any help on this.
> 
> Thanks,
> Naveen
> 
> On Wed, Nov 29, 2017 at 10:33 AM, Noel Kuntze
> <noel.kuntze+strongswan-users-ml at thermi.consulting> wrote:
>> Hi,
>>
>> Please follow the RouteBasedVPN article[1] to the letter and keep your routes in the main routing table
>> to keep it simple. As soon as you have a working setup, THEN you can start making changes.
>>
>> Kind regards
>>
>> Noel
>>
>> [1] https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN
>>
>>
>> On 29.11.2017 09:16, Naveen Neelakanta wrote:
>>> Hi All,
>>>
>>> Need some guidance and help in getting the traffic routed via VTI (
>>> ipsec0 ) interface.I am using the VTI interface to just mark the
>>> traffic and forward.
>>>
>>> I am not able to get the traffic forwarding via VTI( ipsec0) interface
>>> and getting the traffic marked, so that it gets protected.
>>>
>>> i have the ipsec tunnel up with between two device. i see traffic send
>>> from client interface reaching VTI interface , however its not getting
>>> forwarded to eth3 , so that it gets protected.
>>>
>>>
>>> Unix Device1:
>>>
>>>
>>> eth3<————— ipsec0 ( vti )<———————vzsi
>>>
>>>
>>> 10.24.18.209       10.24.18.36           10.24.18.203
>>>
>>>
>>>
>>> Routing rules on the device :
>>>
>>>
>>> ip tunnel add ipsec0 local 10.24.18.36 remote 0.0.0.0 mode vti okey 32 ikey 32
>>>
>>> ip link set ipsec0 up
>>>
>>> ip route add default dev ipsec0 table zs-flow-table-inet
>>>
>>> echo 1 > /proc/sys/net/ipv4/conf/ipsec0/disable_policy
>>>
>>> echo 1 > /proc/sys/net/ipv4/conf/ipsec0/disable_xfrm
>>>
>>> echo 300 zs-flow-table-inet >> /etc/iproute2/rt_tables
>>>
>>>
>>>
>>> ip rule add iif vzsi-p table zs-flow-table-inet
>>>
>>>
>>> ip route add default dev ipsec0 table zs-flow-table-inet
>>>
>>> ip rule add iif ipsec0 table internet-eth3
>>>
>>> ip rule add oif ipsec0 table internet-eth3
>>>
>>> # ip route show table internet-eth3
>>>
>>>
>>>   default via 10.24.18.210 dev eth3
>>>
>>>
>>> The ipsec policy and sa config is present
>>>
>>> SPD entry :
>>>
>>>
>>> src 0.0.0.0/0 dst 0.0.0.0/0
>>>
>>> dir fwd priority 3075
>>>
>>> mark 32/0xffffffff
>>>
>>> tmpl src 10.24.18.35 dst 10.24.18.209
>>>
>>> proto esp reqid 1 mode tunnel
>>>
>>> src 0.0.0.0/0 dst 0.0.0.0/0
>>>
>>> dir in priority 3075
>>>
>>> mark 32/0xffffffff
>>>
>>> tmpl src 10.24.18.35 dst 10.24.18.209
>>>
>>> proto esp reqid 1 mode tunnel
>>>
>>> src 0.0.0.0/0 dst 0.0.0.0/0
>>>
>>> dir out priority 3075
>>>
>>> mark 32/0xffffffff
>>>
>>> tmpl src 10.24.18.209 dst 10.24.18.35
>>>
>>>          proto esp reqid 1 mode tunnel
>>>
>>> SADB:
>>>
>>> src 10.24.18.209 dst 10.24.18.35
>>>
>>> proto esp spi 0xcfe2aa19 reqid 1 mode tunnel
>>>
>>> replay-window 32 flag af-unspec
>>>
>>> mark 32/0xffffffff
>>>
>>> auth-trunc hmac(md5) 0x830c26f2a8fdaa2a1d6f82c9663f0bf3 96
>>>
>>> enc ecb(cipher_null)
>>>
>>> src 10.24.18.35 dst 10.24.18.209
>>>
>>> proto esp spi 0xc377e262 reqid 1 mode tunnel
>>>
>>> replay-window 32 flag af-unspec
>>>
>>> mark 32/0xffffffff
>>>
>>> auth-trunc hmac(md5) 0x99f7adff411b87cb04a652469b6132fd 96
>>>
>>>         enc ecb(cipher_null)
>>>
>>> Issue:
>>>
>>> #ip -s tunnel s ipsec0
>>>
>>> ipsec0: ip/ip  remote any  local 10.24.18.36  ttl inherit  key 32
>>>
>>> RX: Packets    Bytes        Errors CsumErrs OutOfSeq Mcasts
>>>
>>>     0          0            0      0        0        0
>>>
>>> TX: Packets    Bytes        Errors DeadLoop NoRoute  NoBufs
>>>
>>>
>>>        0          0                             32          0
>>> 32           0
>>>
>>> I see the traffic on the ipsec0 interface
>>>
>>> #tcpdump -ni ipsec0
>>>
>>> listening on ipsec0, link-type RAW (Raw IP), capture size 65535 bytes
>>>
>>> 02:18:03.237031 IP 10.24.18.203.52554 > 10.24.18.35.8888: Flags [S],
>>> seq 3484231614, win 29200, options [mss 1460,sackOK,TS val 4061593203
>>> ecr 0,nop,wscale 7], length 0
>>>
>>> # ifconfig ipsec0
>>>
>>>           ipsec0    Link encap:IPIP Tunnel  HWaddr
>>>
>>>           UP RUNNING NOARP  MTU:1500  Metric:1
>>>
>>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>>
>>>           TX packets:0 errors:32 dropped:0 overruns:0 carrier:32
>>>
>>>           collisions:0 txqueuelen:0
>>>
>>>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>>>
>>>
>>> Thanks,
>>>
>>> Naveen
>>

-------------- 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/20171130/575e2f56/attachment.sig>