[strongSwan] __xfrm_policy_check for forwarding tunnel setup

Deepak Khandelwal dazz.87 at gmail.com
Mon Mar 9 07:27:21 CET 2015


>The IPsec endpoint
>does not know whether the packet has to go through the tunnel or to
>the network behind the gateway.

OK. but if the IPSec endpoint specifically tells that go through the tunnel
by route configuration ? should it work. in my case this also is not
working and same problem as i described before.

(eg. in my case on EP-A  20.0.0.2 is tunnel remote endpoint, and route
configured as to reach 45.45.45.1 it should take the tunnel instead of
default gateway)

Traffic endpoints are 35.35.35.1 (at Host X) --- 45.45.45.1 (at Host Y)

Route and IPSec Policy on EP-A
# ip r s
35.35.35.1 via 10.0.0.2 dev eth2  proto gated
45.45.45.1 via 20.0.0.2 dev eth3  proto gated
10.43.4.128/26 dev eth1  proto kernel  scope link  src 10.43.4.166
10.0.0.0/24 dev eth2  proto kernel  scope link  src 10.0.0.1
20.0.0.0/24 dev eth3  proto kernel  scope link  src 20.0.0.1
default via 10.43.4.129 dev eth1  proto gated



# ip xfrm policy
src 0.0.0.0/0 dst 0.0.0.0/0 proto icmp
    dir fwd priority 3002
    tmpl src 20.0.0.2 dst 20.0.0.1
        proto esp reqid 0 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0 proto icmp
    dir in priority 3002
    tmpl src 20.0.0.2 dst 20.0.0.1
        proto esp reqid 16385 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0 proto icmp
    dir out priority 3002
    tmpl src 20.0.0.1 dst 20.0.0.2
        proto esp reqid 16384 mode tunnel

Thanks !

Best regards,
Deepak

On Mon, Mar 9, 2015 at 12:59 AM, Andreas Steffen <
andreas.steffen at strongswan.org> wrote:

> Hi Deepak,
>
> defining a traffic selector of 0.0.0.0/0 on both sides of the tunnel
> does not work since this causes routing problems. The IPsec endpoint
> does not know whether the packet has to go through the tunnel or to
> the network behind the gateway.
>
> Best regards
>
> Andreas
>
> On 03/08/2015 07:13 PM, Deepak Khandelwal wrote:
> > Hi,
> >
> > i have a IPSec Tunnel in forwarding setup as below.
> >
> > Host X ---plain packets--- EP-A ---ipsec tunnel----EP-B ---plain
> > packet--- HOST Y
> >
> > Host X and Host Y communicate to each other (eg. ping) with 2 next hops
> > in between EP-A and EP-B.
> > IPSec Tunnel is setup b/w EP-A and EP-B to encrypt all Traffic
> > (0.0.0.0/0 <http://0.0.0.0/0> -- 0.0.0.0/0 <http://0.0.0.0/0>)
> >
> > i could see the traffic from X reach to EP-A, but from there it is not
> > able to forward packets to EP-B via tunnel.
> > There are XfrmInTmplMismatch  error counters increasing.
> >
> > After debugging, it looks  that the plain packet (skb->sp = NULL)
> > which reach to EP-A, trying to match either with "in" or "fwd" template
> > in __xfrm_policy_check. this checks fails and packets getting dropped
> > with XfrmInTmplMismatch  error counters increasing.
> >
> > in short if plain incoming packets, matches to "fwd" or "in" policy this
> > error counter increase and packets get drop.
> >
> > Is this a expected behavior ? or there any bug in kernel (xfrm) ?
> >
> > # ip xfrm policy
> > src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0> proto
> > icmp
> >     dir fwd priority 3002
> >     tmpl src 20.0.0.2 dst 20.0.0.1
> >         proto esp reqid 0 mode tunnel
> > src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0> proto
> > icmp
> >     dir in priority 3002
> >     tmpl src 20.0.0.2 dst 20.0.0.1
> >         proto esp reqid 16385 mode tunnel
> > src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0> proto
> > icmp
> >     dir out priority 3002
> >     tmpl src 20.0.0.1 dst 20.0.0.2
> >         proto esp reqid 16384 mode tunnel
> >
> >
> > P.S. without ipsec traffic flows fine so there is no route issue.
> >
> >
> > Thanks !
> >
> > Best Regards,
> > Deepak
> >
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.strongswan.org
> > https://lists.strongswan.org/mailman/listinfo/users
> >
>
> --
> ======================================================================
> Andreas Steffen                         andreas.steffen at strongswan.org
> strongSwan - the Open Source VPN Solution!          www.strongswan.org
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===========================================================[ITA-HSR]==
>
>


-- 
Thanks
With Regards
Deepak Khandelwal
91-9461072891
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150309/40b8db6f/attachment.html>


More information about the Users mailing list