[Openswan Users] peer prososes another tunnel's subnet which are to same destination using same endpoints

[Kausalya]

Hi everyone,

            I am currently using openswan version 2.6.21 running in linux
kernel 2.6.23.5(nekey). We are facing issue when multiple tunnels are
configures to the same destination using same endpoints. During the
establishment of Phase II the peer proposes another tunnel's (Tunnel2)
subnet along with its own (Tunnel1) proposal. 

 

Tunnel1 ----
0.0.0.0/0===41.20.19.186<41.20.19.186>[+S=C]---41.20.19.185...196.12.5.82<19
6.12.5.82>[+S=C]===141.20.21.4/30

 

Tunnel2 ----
0.0.0.0/0===41.20.19.186<41.20.19.186>[+S=C]---41.20.19.185...196.12.5.82<19
6.12.5.82>[+S=C]===141.20.21.8/29

 

 

 

I am pasting the messages displayed in auth.log below

 

 

Jun 15 00:27:14 tunnel1-mpvpn pluto[3298]: "Tunnel1" #5335: the peer
proposed: 141.20.21.4/30:0/0 -> 0.0.0.0/0:0/0

Jun 15 00:27:24 tunnel1-mpvpn pluto[3298]: "Tunnel1" #5335: the peer
proposed: 141.20.21.8/29:0/0 -> 0.0.0.0/0:0/0

 

When this happens the ipsec tunnel shows up in whack status but no traffic
passes through the tunnel until a ipsec setup --restart is done. ip xfrm
policy in the box shows the following

 

src 141.20.21.8/29 dst 0.0.0.0/0 

            dir in priority 3107 

            tmpl src 196.12.5.82 dst 41.20.19.186

                        proto esp reqid 166813 mode tunnel

src 0.0.0.0/0 dst 141.20.21.4/30 

            dir out priority 3106 

            tmpl src 0.0.0.0 dst 0.0.0.0

                        proto esp reqid 0 mode transport

src 0.0.0.0/0 dst 141.20.21.8/29 

            dir out priority 3107 

            tmpl src 41.20.19.186 dst 196.12.5.82

                        proto esp reqid 166813 mode tunnel

src 141.20.21.8/29 dst 0.0.0.0/0 

            dir fwd priority 3107 

            tmpl src 196.12.5.82 dst 41.20.19.186

                        proto esp reqid 166813 mode tunnel

src 0.0.0.0/0 dst 0.0.0.0/0 

            dir in priority 0 

src 0.0.0.0/0 dst 0.0.0.0/0 

            dir in priority 0

 

 

As displayed in ip xfrm policy the tunnel that stops to send traffic has
mode set to transport when we are actually using only tunnel mode. Any
suggestions? 

 

 

Thanks in advance,

Kausalya 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20100615/6b4b2731/attachment.html