[Swan] Libreswan 3.31 VTI to XFRM Conversion
Reuben Farrelly
reuben-libreswan at reub.net
Wed Mar 11 10:13:51 UTC 2020
Hi again,
On 11/03/2020 11:33 am, Paul Wouters wrote:
> On Tue, 10 Mar 2020, Reuben Farrelly wrote:
>
>> I'd like to convert an existing, working configuration from VTI to
>> XFRM support. But obviously I am missing something as it doesn't
>> seem to be a straightforward change.
>>
>> My existing config looks like this:
>>
>> conn router-2.reub.net-ipv4
>
>> leftsubnet=0.0.0.0/0
>
>> rightsubnet=0.0.0.0/0
>
>> mark=1/0xffffffff
>> vti-interface=vti-1
>> leftvti=192.168.6.1/30
>>
>> That all works just fine. It is entirely route based, whatever
>> traffic is routed down the link is encrypted, and it works as expected.
>>
>> However to convert over to use xfrm I changed the following:
>>
>> - change leftvti= to be leftinterface-ip=
>> - change vti-interface= to ipsec-interface=
>
> Yes, but it has to be either "yes" (meaning 1) or a number.
>
>> - remove mark= (is this even necessary for vti anymore?)
>
> It was needed for VTI but not for XFRMi. We should probably not allow it
> with ipsec-interface= set.
Ok so my current xfrm config now looks like this:
conn router-2.reub.net-ipv4
left=172.105.178.21
leftid=@lightning.reub.net
leftsubnet=0.0.0.0/0
right=%any
rightid=router-2 at reub.net
rightsubnet=0.0.0.0/0
authby=secret
ikev2=insist
ikelifetime=86400s
salifetime=3600s
# IOS XE
ike=aes-sha2_512;dh19
# Classic IOS
#ike=aes-sha2_512;dh5
dpddelay=15
dpdtimeout=45
dpdaction=clear
auto=add
ipsec-interface=yes
leftinterface-ip=192.168.6.1/30
>> asynchronous network error report on eth0 (172.105.178.21:500) for
>> message to 1.144.144.75 port 500, complainant 172.105.178.21: No
>> route to host [errno 113, origin ICMP type 3 code 1 (not authenticated)]
>> Mar 10 11:27:35.161044: "router-2.reub.net-ipv4"[1] 1.144.144.75 #2:
>> liveness_check - peer 1.144.144.75 has not responded in 59 seconds,
>> with a timeout of 45, taking action:clear
>
> This looks like an imploded route that caused IKE traffic to fail?
>
>> Mar 10 11:27:35.185931: "router-2.reub.net-ipv4"[1] 1.144.144.75:
>> unroute-client output: leftsubet == rightsubnet = 0.0.0.0/0 can not
>> add route
>
> this is fine. you need to do the routing into the ipsec interface for
> 0/0 to 0/0 tunnels.
>
>> Mar 10 11:25:50.161136: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
>> received unsupported NOTIFY v2N_SET_WINDOW_SIZE
>
> You can ignore that.
>
>> Mar 10 11:25:50.161141: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
>> received unsupported NOTIFY v2N_NON_FIRST_FRAGMENTS_ALSO
>
> And that.
>
>> Mar 10 11:25:50.202585: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
>> route-client output: leftsubet == rightsubnet = 0.0.0.0/0 can not add
>> route
>
> This is okay, you need to route manually because only you know what
> traffic should go into the ipsecX interface.
At this stage I only need to get 192.168.6.1/30 talking to the far end
IPSec tunnel on 192.168.6.2/30 - so only a directly connected subnet for
now. But yes I'd like to have it work in such a way that I only need to
route traffic down the tunnel using standard IP routing and not have to
reconfigure anything with the tunnel in future if this changes.
> Mar 10 11:25:50.210179: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
> route-client output: /usr/libexec/ipsec/_updown.netkey: doroute "ip -4
> rule add prio 100 to 0.0.0.0/0 fwmark 1/0xffffffff lookup 50" failed
> (RTNETLINK answers: Operation not supported)
>
> This seems to indicate you mistakenly used the mark= option with XFRMi.
Even without mark= configured the mark option seems to still be set.
As it turns out, this error was caused by missing bits of kernel support
for the use of 'ip rule'. As this wasn't required in the past I hadn't
had to enable advanced IP routing and a bunch of other kernel options
for the 'ip link' arguments to be accepted. To be fair this wasn't
really an issue with libreswan, but the fact that 'ip rule' didn't work
without them meant that there is a soft dependency there that perhaps
should be documented, or present in an error message.
So things are looking better now:
Mar 11 18:36:31.414035: Kernel supports NIC esp-hw-offload
Mar 11 18:36:31.414176: adding interface eth0 172.105.178.21:500
Mar 11 18:36:31.414207: adding interface eth0 172.105.178.21:4500
Mar 11 18:36:31.414223: adding interface lo 127.0.0.1:500
Mar 11 18:36:31.414239: adding interface lo 127.0.0.1:4500
Mar 11 18:36:31.414272: adding interface lo [::1]:500
Mar 11 18:36:31.414290: adding interface eth0
[2400:8907::f03c:92ff:fe08:4896]:500
Mar 11 18:36:31.416194: loading secrets from "/etc/ipsec.secrets"
Mar 11 18:36:31.416541: loading secrets from
"/etc/ipsec.d/router-2.reub.net-ipv4.secrets"
Mar 11 18:36:46.396013: "router-2.reub.net-ipv4"[1] 1.144.144.75: local
IKE proposals (IKE SA responder matching remote proposals):
Mar 11 18:36:46.396057: "router-2.reub.net-ipv4"[1] 1.144.144.75:
1:IKE=AES_CBC_256+AES_CBC_128-HMAC_SHA2_512-HMAC_SHA2_512_256-ECP_256
Mar 11 18:36:46.396071: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
proposal 1:IKE=AES_CBC_256-HMAC_SHA2_512-HMAC_SHA2_512_256-ECP_256
chosen from remote proposals
1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_512;PRF=HMAC_SHA2_384;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA2_384_192;DH=ECP_256;DH=MODP2048;DH=ECP_521;DH=MODP1536[first-match]
Mar 11 18:36:46.397249: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
STATE_PARENT_R1: received v2I1, sent v2R1 {auth=IKEv2 cipher=AES_CBC_256
integ=HMAC_SHA2_512_256 prf=HMAC_SHA2_512 group=DH19}
Mar 11 18:36:46.437932: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
processing decrypted IKE_AUTH request: SK{V,IDi,AUTH,SA,TSi,TSr,N,N,N,N}
Mar 11 18:36:46.437957: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
IKEv2 mode peer ID is ID_USER_FQDN: 'router-2 at reub.net'
Mar 11 18:36:46.438034: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
authenticated using authby=secret
Mar 11 18:36:46.438130: "router-2.reub.net-ipv4"[1] 1.144.144.75: local
ESP/AH proposals (IKE_AUTH responder matching remote ESP/AH proposals):
Mar 11 18:36:46.438138: "router-2.reub.net-ipv4"[1] 1.144.144.75:
1:ESP=AES_GCM_C_256-NONE-NONE-DISABLED
Mar 11 18:36:46.438143: "router-2.reub.net-ipv4"[1] 1.144.144.75:
2:ESP=AES_GCM_C_128-NONE-NONE-DISABLED
Mar 11 18:36:46.438147: "router-2.reub.net-ipv4"[1] 1.144.144.75:
3:ESP=AES_CBC_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-NONE-DISABLED
Mar 11 18:36:46.438152: "router-2.reub.net-ipv4"[1] 1.144.144.75:
4:ESP=AES_CBC_128-HMAC_SHA2_512_256+HMAC_SHA2_256_128-NONE-DISABLED
Mar 11 18:36:46.438163: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
proposal 1:ESP=AES_CBC_256-HMAC_SHA2_256_128-DISABLED SPI=59169665
chosen from remote proposals
1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED[first-match]
Mar 11 18:36:46.438195: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
received unsupported NOTIFY v2N_SET_WINDOW_SIZE
Mar 11 18:36:46.438200: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
received unsupported NOTIFY v2N_NON_FIRST_FRAGMENTS_ALSO
Mar 11 18:36:46.479732: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
route-client output: leftsubet == rightsubnet = 0.0.0.0/0 can not add route
Mar 11 18:36:46.486800: "router-2.reub.net-ipv4"[1] 1.144.144.75 #2:
negotiated connection [0.0.0.0-255.255.255.255:0-65535 0] ->
[0.0.0.0-255.255.255.255:0-65535 0]
Mar 11 18:36:46.486825: "router-2.reub.net-ipv4"[1] 1.144.144.75 #2:
STATE_V2_IPSEC_R: IPsec SA established tunnel mode {ESP/NAT=>0x59169665
<0xb940b851 xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATOA=none
NATD=1.144.144.75:4500 DPD=active}
Mar 11 18:36:46.545742: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
STATE_PARENT_R2: received v2I2, PARENT SA established
Mar 11 18:46:23.141516: packet from 146.88.240.4:49654: 0-byte length of
ISAKMP Message is smaller than minimum
Mar 11 18:46:23.141538: packet from 146.88.240.4:49654: received packet
with mangled IKE header - dropped
Mar 11 19:30:34.981137: "router-2.reub.net-ipv4"[1] 1.144.144.75: local
ESP/AH proposals (CREATE_CHILD_SA responder matching remote ESP/AH
proposals):
Mar 11 19:30:34.981205: "router-2.reub.net-ipv4"[1] 1.144.144.75:
1:ESP=AES_GCM_C_256-NONE-ECP_256-DISABLED
Mar 11 19:30:34.981211: "router-2.reub.net-ipv4"[1] 1.144.144.75:
2:ESP=AES_GCM_C_128-NONE-ECP_256-DISABLED
Mar 11 19:30:34.981217: "router-2.reub.net-ipv4"[1] 1.144.144.75:
3:ESP=AES_CBC_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-ECP_256-DISABLED
Mar 11 19:30:34.981223: "router-2.reub.net-ipv4"[1] 1.144.144.75:
4:ESP=AES_CBC_128-HMAC_SHA2_512_256+HMAC_SHA2_256_128-ECP_256-DISABLED
Mar 11 19:30:34.981238: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
proposal 1:ESP=AES_CBC_256-HMAC_SHA2_256_128-ECP_256-DISABLED
SPI=df4e8bde chosen from remote proposals
1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;DH=ECP_256;ESN=DISABLED[first-match]
Mar 11 19:30:34.983938: "router-2.reub.net-ipv4"[1] 1.144.144.75 #3:
negotiated new IPsec SA [0.0.0.0-255.255.255.255:0-65535 0] ->
[0.0.0.0-255.255.255.255:0-65535 0]
Mar 11 19:30:34.983994: "router-2.reub.net-ipv4"[1] 1.144.144.75 #3:
negotiated connection [0.0.0.0-255.255.255.255:0-65535 0] ->
[0.0.0.0-255.255.255.255:0-65535 0]
Mar 11 19:30:34.984006: "router-2.reub.net-ipv4"[1] 1.144.144.75 #3:
STATE_V2_IPSEC_R: IPsec SA established tunnel mode {ESP/NAT=>0xdf4e8bde
<0x84709510 xfrm=AES_CBC_256-HMAC_SHA2_256_128-DH19 NATOA=none
NATD=1.144.144.75:4500 DPD=active}
Mar 11 19:30:35.032835: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
received Delete SA payload: delete IPsec State #2 now
Mar 11 19:30:35.032858: "router-2.reub.net-ipv4"[1] 1.144.144.75 #2:
deleting other state #2 (STATE_V2_IPSEC_R) aged 3228.594s and NOT
sending notification
Mar 11 19:30:35.032890: "router-2.reub.net-ipv4"[1] 1.144.144.75 #2: ESP
traffic information: in=383KB out=0B
Mar 11 19:30:35.032996: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
STATE_PARENT_R2: received v2I2, PARENT SA established
Mar 11 20:24:38.019055: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
proposal 1:ESP=AES_CBC_256-HMAC_SHA2_256_128-ECP_256-DISABLED
SPI=387d8674 chosen from remote proposals
1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;DH=ECP_256;ESN=DISABLED[first-match]
Mar 11 20:24:38.021403: "router-2.reub.net-ipv4"[1] 1.144.144.75 #4:
negotiated new IPsec SA [0.0.0.0-255.255.255.255:0-65535 0] ->
[0.0.0.0-255.255.255.255:0-65535 0]
Mar 11 20:24:38.021419: "router-2.reub.net-ipv4"[1] 1.144.144.75 #4:
negotiated connection [0.0.0.0-255.255.255.255:0-65535 0] ->
[0.0.0.0-255.255.255.255:0-65535 0]
Mar 11 20:24:38.021429: "router-2.reub.net-ipv4"[1] 1.144.144.75 #4:
STATE_V2_IPSEC_R: IPsec SA established tunnel mode {ESP/NAT=>0x387d8674
<0x6a994606 xfrm=AES_CBC_256-HMAC_SHA2_256_128-DH19 NATOA=none
NATD=1.144.144.75:4500 DPD=active}
Mar 11 20:24:38.085941: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
received Delete SA payload: delete IPsec State #3 now
Mar 11 20:24:38.085956: "router-2.reub.net-ipv4"[1] 1.144.144.75 #3:
deleting other state #3 (STATE_V2_IPSEC_R) aged 3243.104s and NOT
sending notification
Mar 11 20:24:38.085979: "router-2.reub.net-ipv4"[1] 1.144.144.75 #3: ESP
traffic information: in=385KB out=0B
Mar 11 20:24:38.086059: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
STATE_PARENT_R2: received v2I2, PARENT SA established
I had to manually set an IP address on the ipsec1 interface, but it
still doesn't work.
lightning ~ # ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP mode DEFAULT group default qlen 1000
link/ether f2:3c:92:08:48:96 brd ff:ff:ff:ff:ff:ff
5: ipsec1 at eth0: <NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
mode DEFAULT group default qlen 1000
link/none
lightning ~ # ip xfrm state
src 1.144.144.75 dst 172.105.178.21
proto esp spi 0x6a994606 reqid 16393 mode tunnel
replay-window 32 flag af-unspec
output-mark 0x1
auth-trunc hmac(sha256)
0xe35ff0a1416b27730d7f8fb24f95a1d9d12a1a228f6d066d3db61f8d6863d1b6 128
enc cbc(aes)
0x0098ade94690231c3fb762d02721b7ad6da4ccab469fd70c1d48cf43df3c80a7
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0xd14, oseq 0x0, bitmap 0xffffffff
if_id 0x1
src 172.105.178.21 dst 1.144.144.75
proto esp spi 0x387d8674 reqid 16393 mode tunnel
replay-window 32 flag af-unspec
output-mark 0x1
auth-trunc hmac(sha256)
0xac13eb8e16c96d75b1e45de834bafa8aaee3529b055043f1db3a8f57146c3d6b 128
enc cbc(aes)
0x813222dd3fdd3fd918b73990226ef48961eb4f84fd217ccc1be4a4324a86bfef
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x504, bitmap 0x00000000
if_id 0x1
lightning ~ #
lightning ~ # ip -d link show dev ipsec1
5: ipsec1 at eth0: <NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
mode DEFAULT group default qlen 1000
link/none promiscuity 0 minmtu 68 maxmtu 65535
xfrm if_id 0x1 addrgenmode random numtxqueues 1 numrxqueues 1
gso_max_size 65536 gso_max_segs 65535
lightning ~ # ip -s link show dev ipsec1
5: ipsec1 at eth0: <NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
mode DEFAULT group default qlen 1000
link/none
RX: bytes packets errors dropped overrun mcast
1130640 13460 0 0 0 0
TX: bytes packets errors dropped carrier collsns
170268 2027 0 12 0 0
lightning ~ #
lightning ~ # ip route
default via 172.105.178.1 dev eth0 metric 2
172.105.178.0/24 dev eth0 proto kernel scope link src 172.105.178.21
192.168.6.0/30 dev ipsec1 proto kernel scope link src 192.168.6.1
lightning ~ #
lightning ~ # ip rule show
0: from all lookup local
100: from all fwmark 0x1 lookup 50
32766: from all lookup main
32767: from all lookup default
lightning ~ #
Looks a lot like IPSec is happy but the routing/interface side of things
is not. The Cisco device on the far end is sending packets but not
receiving any. The ipsec1 interface is sending and receiving packets
though. The Cisco seems happy with the negotiation too so looks like
we're close - but not quite there.
I've made no changes at all on the Cisco and I assume that I won't need
to do so for this to work given it did previously with vti.
Reuben
More information about the Swan
mailing list