[Swan] vxlan support
António Silva
asilva at wirelessmundi.com
Tue Jan 23 22:10:21 UTC 2018
I try to set the leftprotoport / rightprotoport=udp/4789 , i can ping
the ip on boxB going trough the vxlan but the traffic is not
encrypted... is not going to the ipsec tunnel... on side is behind NAT
but the ipsec tunnel stablish fine.
Sowmini, you suggest using two tunnels, how should they be?
With this configuration i should have on side, no?
there is my configuration:
BoxA
# configure vxlan
ip link add vxlan0 type vxlan id 1 dstport 4789
ip addr add 192.168.10.1/24 dev vxlan0
bridge fdb add to 00:00:00:00:00:00 dst 10.10.100.10 dev vxlan0
ip l set dev vxlan0 up
ipsec.conf:
conn boxA-nat
rightsubnet=vhost:%priv
also=boxA
conn boxA
pfs=no
type=transport
auto=start
phase2=esp
sha2-truncbug=yes
authby=secret
keyingtries=3
ikelifetime=8h
salifetime=1h
leftid=10.10.100.100
left=%defaultroute
leftprotoport=udp/4789
ikev2=never
right=10.10.100.10
rightid=10.10.100.106
rightprotoport=udp/4789
dpddelay=30
dpdtimeout=60
dpdaction=hold
BoxB:
# configure vxlan
ip link add vxlan0 type vxlan id 1 dstport 4789
ip addr add 192.168.10.2/24 dev vxlan0
bridge fdb append to 00:00:00:00:00:00 dst 10.10.100.100 dev vxlan0
ip l set dev vxlan0 up
ipsec.conf:
conn boxB-nat
rightsubnet=vhost:%priv
also=boxB
conn boxB
pfs=no
type=transport
auto=add
phase2=esp
sha2-truncbug=yes
authby=secret
keyingtries=3
ikelifetime=8h
salifetime=1h
left=10.10.100.10
leftprotoport=udp/4789
ikev2=never
leftid=10.10.100.10
right=10.10.100.100
rightid=10.10.100.100
rightprotoport=udp/4789
dpddelay=30
dpdtimeout=60
dpdaction=hold
Logs from boxB
Jan 23 23:39:46 a2 pluto[27131]: "boxB-nat"[1] 10.10.100.100 #1:
responding to Main Mode from unknown peer 10.10.100.100
Jan 23 23:39:46 a2 pluto[27131]: "boxB-nat"[1] 10.10.100.100 #1:
WARNING: connection boxB-nat PSK length of 7 bytes is too short for
sha2_256 PRF in FIPS mode (16 bytes required)
Jan 23 23:39:46 a2 pluto[27131]: "boxB-nat"[1] 10.10.100.100 #1:
transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Jan 23 23:39:46 a2 pluto[27131]: "boxB-nat"[1] 10.10.100.100 #1:
STATE_MAIN_R1: sent MR1, expecting MI2
Jan 23 23:39:46 a2 pluto[27131]: "boxB-nat"[1] 10.10.100.100 #1:
transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Jan 23 23:39:46 a2 pluto[27131]: "boxB-nat"[1] 10.10.100.100 #1:
STATE_MAIN_R2: sent MR2, expecting MI3
Jan 23 23:39:46 a2 pluto[27131]: "boxB-nat"[1] 10.10.100.100 #1: Peer ID
is ID_IPV4_ADDR: '10.10.100.100'
Jan 23 23:39:46 a2 pluto[27131]: "boxB-nat"[1] 10.10.100.100 #1:
transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Jan 23 23:39:46 a2 pluto[27131]: "boxB-nat"[1] 10.10.100.100 #1: new NAT
mapping for #1, was 10.10.100.100:500, now 10.10.100.100:9816
Jan 23 23:39:46 a2 pluto[27131]: "boxB-nat"[1] 10.10.100.100 #1:
STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=PRESHARED_KEY
cipher=aes_256 integ=sha2_256 group=MODP2048}
Jan 23 23:39:47 a2 pluto[27131]: "boxB-nat"[1] 10.10.100.100 #1: the
peer proposed: 10.10.100.10/32:17/4789 -> 192.168.1.97/32:17/4789
Jan 23 23:39:47 a2 pluto[27131]: "boxB-nat"[1] 10.10.100.100 #1:
NAT-Traversal: received 2 NAT-OA. Using first, ignoring others
Jan 23 23:39:47 a2 pluto[27131]: "boxB-nat"[1] 10.10.100.100 #2:
responding to Quick Mode proposal {msgid:db11192c}
Jan 23 23:39:47 a2 pluto[27131]: "boxB-nat"[1] 10.10.100.100 #2: us:
10.10.100.10<10.10.100.10>:17/4789
Jan 23 23:39:47 a2 pluto[27131]: "boxB-nat"[1] 10.10.100.100 #2: them:
10.10.100.100<10.10.100.100>:17/4789===192.168.1.97/32
Jan 23 23:39:47 a2 pluto[27131]: "boxB-nat"[1] 10.10.100.100 #2:
transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Jan 23 23:39:47 a2 pluto[27131]: "boxB-nat"[1] 10.10.100.100 #2:
STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
transport mode {ESP/NAT=>0x6e4fb7e7 <0xd041d2f6 xfrm=AES_128-HMAC_SHA1
NATOA=192.168.1.97 NATD=10.10.100.100:9816 DPD=active}
Jan 23 23:39:47 a2 pluto[27131]: "boxB-nat"[1] 10.10.100.100 #2:
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Jan 23 23:39:47 a2 pluto[27131]: "boxB-nat"[1] 10.10.100.100 #2:
STATE_QUICK_R2: IPsec SA established transport mode {ESP/NAT=>0x6e4fb7e7
<0xd041d2f6 xfrm=AES_128-HMAC_SHA1 NATOA=192.168.1.97
NATD=10.10.100.100:9816 DPD=active}
[23:45:14][a2][~]# ip xfrm s
src 10.10.100.100 dst 10.10.100.10
proto esp spi 0xd041d2f6 reqid 16397 mode transport
replay-window 32
auth-trunc hmac(sha1) 0xfdda97ee7fde32a70e7e1ce5b01920188219991b 96
enc cbc(aes) 0xf51066695322609bca3f4c5bbcb62a3e
encap type espinudp sport 9816 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
sel src 10.10.100.100/32 dst 10.10.100.10/32 proto udp sport 4789
dport 4789
src 10.10.100.10 dst 10.10.100.100
proto esp spi 0x6e4fb7e7 reqid 16397 mode transport
replay-window 32
auth-trunc hmac(sha1) 0xdbdeb0f206d448b2f9b5d1935261bd349668b500 96
enc cbc(aes) 0x1f0e7b47308b63712770662021cce883
encap type espinudp sport 4500 dport 9816 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
sel src 10.10.100.10/32 dst 10.10.100.100/32 proto udp sport 4789
dport 4789
[23:47:32][a2][~]# ip xfrm p
src 10.10.100.10/32 dst 10.10.100.100/32 proto udp sport 4789 dport 4789
dir out priority 1952 ptype main
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 16397 mode transport
src 10.10.100.100/32 dst 10.10.100.10/32 proto udp sport 4789 dport 4789
dir in priority 1952 ptype main
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 16397 mode transport
On 01/23/2018 08:14 PM, António Silva wrote:
> Thanks for the reply.
>
>
> My idea is to have traffic between vxlan encrypted:
>
> host1/vxlan1
> | x |
> | x |
> ipsec tunel
> | x |
> | x |
> host2/vxlan1
>
>
> Do i still need to connect to tunnels?
>
> I'm trying to configure it now..
>
> On 01/23/2018 06:35 PM, Sowmini Varadhan wrote:
>> On (01/23/18 12:30), Paul Wouters wrote:
>>> Why two? Are both peers using an ephemeral souce port? If it is port
>>> 4789 to port 4789, wouldn't one tunnel be enough?
>> I'm assuming that the local host is both sends (to other node's
>> udp port 4789) and receives (on udp port 4789 from other peers)
>> vxlan packets, and that we want ipsec for both directions.
>>
>> Depends on what Antonio is trying to achieve, I suppose.
>>
>> --Sowmini
>>
>>
>
--
Saludos / Regards / Cumprimentos
António Silva
More information about the Swan
mailing list