[Swan] XFRMi Interface route based IPSec with right=%any

Rav Ya ravin.ya90 at gmail.com
Tue Apr 28 22:27:38 UTC 2020


Hello All,

Can someone please advise me on the below.


*Overview:*

I have two connection profiles on my responder with right=%any. For both
the connections the rightsubnet/leftsubnet are set to 0.0.0.0/0.  Setting
up an XFRMi interface for each connection.



*Question:* With this configuration, my the first tunnel comes up
successfully but my second tunnel fails with “route already in use” error?


Given that I have two different XRFMi interfaces shouldn’t we allow route (
0.0.0.0/0 ->  0.0.0.0/0 subnets) for individual XFRMi to run iBGP? What am
I missing? Any recommendations please?


Below are some captures and logs that highlight the issue.


*XFRMi = ipsec1*

"gateway01": 0.0.0.0/0===10.11.0.254
<10.11.0.254>[@libswan]...%any[@strswan01]===0.0.0.0/0; unrouted; eroute
owner: #0



*Connection Successful: *

"gateway01"[1]: 0.0.0.0/0===10.11.0.254
<10.11.0.254>[@libswan]...10.11.0.1[@strswan01]===0.0.0.0/0; erouted;
eroute owner: #2



Apr 28 17:28:56.693693: | add inbound eroute 0.0.0.0/0:0 --0-> 0.0.0.0/0:0
=> tun.10000 at 10.11.0.254 using reqid 16397 (raw_eroute)

Apr 28 17:28:56.693697: | IPsec Sa SPD priority set to 2097151

Apr 28 17:28:56.693699: | netlink_raw_eroute netlink: XFRMA_IF_ID  1
req.n.nlmsg_type=25

Apr 28 17:28:56.693713: | *raw_eroute result=success*



Apr 28 17:28:56.693727: | FOR_EACH_CONNECTION_... in route_owner

Apr 28 17:28:56.693729: |  conn gateway01 mark 0/00000000, 0/00000000 vs

Apr 28 17:28:56.693731: |  conn gateway01 mark 0/00000000, 0/00000000

Apr 28 17:28:56.693733: |  conn gateway01 mark 0/00000000, 0/00000000 vs

Apr 28 17:28:56.693735: |  conn gateway02 mark 0/00000000, 0/00000000

Apr 28 17:28:56.693738: |  conn gateway01 mark 0/00000000, 0/00000000 vs

Apr 28 17:28:56.693740: |  conn gateway01 mark 0/00000000, 0/00000000

_ROUTEApr 28 17:28:56.693744: *| route owner of "gateway01"[1] 10.11.0.1
unrouted: NULL; eroute owner: NULL*

Apr 28 17:28:56.693752: | route_and_eroute with c: gateway01 (next: none)
ero:null esr:{(nil)} ro:null rosr:{(nil)} and state: #2

Apr 28 17:28:56.693755: | priority calculation of connection "gateway01" is
0x1fffff

Apr 28 17:28:56.693760: | eroute_connection add eroute 0.0.0.0/0:0 --0->
0.0.0.0/0:0 => tun.0 at 10.11.0.1 using reqid 16397 (raw_eroute)

Apr 28 17:28:56.693763: | IPsec Sa SPD priority set to 2097151

Apr 28 17:28:56.693765: | netlink_raw_eroute netlink: XFRMA_IF_ID  1
req.n.nlmsg_type=25

Apr 28 17:28:56.693774: | raw_eroute result=success

Apr 28 17:28:56.693779: | running updown command "ipsec _updown" for verb up

Apr 28 17:28:56.693781: | command executing up-client

Apr 28 17:28:56.693802: | executing up-client: PLUTO_VERB='up-client'
PLUTO_VERSION='2.0' PLUTO_CONNECTION='gateway01'
PLUTO_VIRT_INTERFACE='ipsec1' PLUTO_INTERFACE='ens224'
PLUTO_XFRMI_ROUTE='yes' PLUTO_NEXT_HOP='10.11.0.1' PLUTO_ME='10.11.0.254'
PLUTO_MY_ID='@libswan' PLUTO_MY_CLIENT='0.0.0.0/0'
PLUTO_MY_CLIENT_NET='0.0.0.0' PLUTO_MY_CLIENT_MASK='0.0.0.0'
PLUTO_MY_PORT='0' PLUTO_MY_PROTOCOL='0' PLUTO_SA_REQID='16396'
PLUTO_SA_TYPE='ESP' PLUTO_PEER='10.11.0.1' PLUTO_PEER_ID='@strswan01'
PLUTO_PEER_CLIENT='0.0.0.0/0' PLUTO_PEER_CLIENT_NET='0.0.0.0'
PLUTO_PEER_CLIENT_MASK='0.0.0.0' PLUTO_PEER_PORT='0'
PLUTO_PEER_PROTOCOL='0' PLUTO_PEER_CA='' PLUTO_STACK='netkey'
PLUTO_ADDTIME='0'
PLUTO_CONN_POLICY='PSK+ENCRYPT+TUNNEL+PFS+DONT_REKEY+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO'
PLUTO_CONN_KIND='CK_INSTANCE' PLUTO_CONN_ADDRFAMILY='ipv4' XAUTH_FAILED=0
PLUTO_IS_PEER_CISCO='0' PLUTO_PEER_DNS_INFO='' PLUTO_PEER_DOMAIN_INFO=''
PLUTO_PEER_BANNER='' PLUTO_CFG_SERVER='0' PLUTO_CFG_CLIENT='0'
PLUTO_NM_CONFIGURED='0' PLUTO_XFRMI_FWMARK='1/0...







*XFRMi= ipsec2*

"gateway02": 0.0.0.0/0===10.11.0.254
<10.11.0.254>[@libswan]...%any[@strswan02]===0.0.0.0/0; unrouted; eroute
owner: #0



*Connection Fail: *

"gateway02"[1]: 0.0.0.0/0===10.11.0.254
<10.11.0.254>[@libswan]...10.11.0.2[@strswan02]===0.0.0.0/0; unrouted;
eroute owner: #0



FOR_EACH_CONNECTION_... in ISAKMP_SA_established

Apr 28 17:28:58.267631: |     #3 spent 1.58 milliseconds

Apr 28 17:28:58.267633: | install_ipsec_sa() for #4: inbound and outbound

Apr 28 17:28:58.267635: | could_route called for gateway02
(kind=CK_INSTANCE)

Apr 28 17:28:58.267637: | FOR_EACH_CONNECTION_... in route_owner

Apr 28 17:28:58.267639: |  conn gateway02 mark 0/00000000, 0/00000000 vs

Apr 28 17:28:58.267641: |  conn gateway02 mark 0/00000000, 0/00000000

Apr 28 17:28:58.267643: |  conn gateway02 mark 0/00000000, 0/00000000 vs

Apr 28 17:28:58.267645: |  conn gateway01 mark 0/00000000, 0/00000000

Apr 28 17:28:58.267647: |  conn gateway02 mark 0/00000000, 0/00000000 vs

Apr 28 17:28:58.267649: |  conn gateway02 mark 0/00000000, 0/00000000

Apr 28 17:28:58.267650: |  conn gateway02 mark 0/00000000, 0/00000000 vs

Apr 28 17:28:58.267652: |  conn gateway01 mark 0/00000000, 0/00000000

Apr 28 17:28:58.267658: | route owner of "gateway02"[1] 10.11.0.2 unrouted:
"gateway01"[1] 10.11.0.1 erouted; eroute owner: "gateway01"[1] 10.11.0.1
erouted

Apr 28 17:28:58.267662: *"gateway02"[1] 10.11.0.2 #3: cannot route -- route
already in use for "gateway01"[1] 10.11.0.1*

Apr 28 17:28:58.267665: | *ikev2_child_sa_respond returned STF_FATAL*

Apr 28 17:28:58.267667: | ikev2_parent_inI2outR2_continue_tail returned
STF_FATAL

Apr 28 17:28:58.267670: |   #3 spent 1.62 milliseconds in processing:
Responder: process IKE_AUTH request in v2_dispatch()

Apr 28 17:28:58.267672: | MD.ST contains the CHILD SA #4

Apr 28 17:28:58.267676: | suspend processing: state #3 connection
"gateway02"[1] 10.11.0.2 from 10.11.0.2:4500 (in
complete_v2_state_transition() at ikev2.c:3229)

Apr 28 17:28:58.267679: | start processing: state #4 connection
"gateway02"[1] 10.11.0.2 from 10.11.0.2:4500 (in
complete_v2_state_transition() at ikev2.c:3229)

Apr 28 17:28:58.267682: | #4 complete_v2_state_transition() UNDEFINED ->
V2_IPSEC_R with status STF_FATAL; transition.[from]state=PARENT_R1

Apr 28 17:28:58.267685: "gateway02"[1] 10.11.0.2 #4: encountered fatal
error in state STATE_UNDEFINED



Thank you,

-Rav Ya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20200428/0fbe33bc/attachment.html>


More information about the Swan mailing list