[ovs-discuss] ipsec_gre not working in OpenWRT

Fri Dec 8 12:52:24 UTC 2017

Hi Guys

I am trying to enable ipsec_gre tunnelling between two openwrt.
I created a physical and internal bridge, based on
http://docs.openvswitch.org/en/latest/howto/userspace-tunneling/ (although
I am using kernel space tunnelling)

# Creates Internal Bridge
ovs-vsctl --may-exist add-br br-int \
  -- set Bridge br-int datapath_type=$DATAPATH \
    -- br-set-external-id br-int bridge-id br-int \
      -- set bridge br-int fail-mode=standalone

ovs-vsctl add-port br-int gre0  -- set interface gre0 type=$PROTOCOL
options:remote_ip=$THERE options:psk=test123
ifconfig br-int $TUN_HERE mtu 1400 up

# Creates physical Bridge
ovs-vsctl --may-exist add-br br-phy \
  -- set Bridge br-phy datapath_type=$DATAPATH \
      -- br-set-external-id br-phy bridge-id br-phy \
          -- set bridge br-phy fail-mode=standalone \
               other_config:hwaddr=$BRIDGEID

ovs-vsctl --timeout 10 add-port br-phy $DEV
ifconfig $DEV 0.0.0.0 mtu 2000
ifconfig br-phy $HERE mtu 2000 up

Everything works fine when $PROTOCOL is gre.
I can see decapsulated packages coming from the gre_sys interface, and
being received by br-int
I can actually ping between br-int (1.1.1.1 <=> 1.1.1.2)

But if PROTOCOL is ipsec_gre, it doesnt work
ovs-monitor-ipsec is running, and configuring security associations between
the two hosts.
I can see ESP traffic through br-phy
I can see packets being received in the gre_sys interface (meaning SA is
ok), but receiving switch is failing to reply ARP

*root at cpe5:~/TEST# tcpdump -i gre_sys -n -nn*
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gre_sys, link-type EN10MB (Ethernet), capture size 262144 bytes
09:32:24.807643 ARP, Request who-has 1.1.1.2 tell 1.1.1.1, length 28
09:32:25.807685 ARP, Request who-has 1.1.1.2 tell 1.1.1.1, length 28

The only difference I see when compare gre with ipsec_gree, is that there
is some missing flows for tunneling when in ipsec_gre mode

In gre mode, I see

*root at cpe5:~# ovs-appctl dpctl/dump-flows*
# There flows are installed in both cases
recirc_id(0),in_port(4),eth(src=d8:58:d7:00:2e:c9,dst=d8:58:d7:00:2e:c6),eth_type(0x0800),ipv4(frag=no),
packets:8, bytes:1032, used:0.430s, actions:3
recirc_id(0),in_port(4),eth(src=d8:58:d7:00:2e:c9,dst=d8:58:d7:00:2e:c6),eth_type(0x0806),
packets:1, bytes:60, used:2.420s, actions:3
recirc_id(0),in_port(3),eth(src=d8:58:d7:00:2e:c6,dst=d8:58:d7:00:2e:c9),eth_type(0x0800),ipv4(frag=no),
packets:8, bytes:1032, used:0.430s, actions:4
recirc_id(0),in_port(3),eth(src=d8:58:d7:00:2e:c6,dst=d8:58:d7:00:2e:c9),eth_type(0x0806),
packets:0, bytes:0, used:never, actions:4

# There flows get installed only in GRE mode. They are missing when
IPSEC_GRE is in use
recirc_id(0),in_port(1),eth(src=1a:6b:2d:47:f3:43,dst=5a:a4:e4:d9:25:43),eth_type(0x0806),
packets:0, bytes:0, used:never,
actions:set(tunnel(dst=192.168.222.204,ttl=64,flags(df))),2
recirc_id(0),in_port(1),eth(src=1a:6b:2d:47:f3:43,dst=5a:a4:e4:d9:25:43),eth_type(0x0800),ipv4(tos=0/0x3,frag=no),
packets:7, bytes:686, used:0.430s,
actions:set(tunnel(dst=192.168.222.204,ttl=64,flags(df))),2
recirc_id(0),tunnel(src=192.168.222.204,dst=192.168.222.205,ttl=64,flags(-df-csum)),in_port(2),skb_mark(0),eth(src=5a:a4:e4:d9:25:43,dst=1a:6b:2d:47:f3:43),eth_type(0x0806),
packets:0, bytes:0, used:never, actions:1
recirc_id(0),tunnel(src=192.168.222.204,dst=192.168.222.205,ttl=64,flags(-df-csum)),in_port(2),skb_mark(0),eth(src=5a:a4:e4:d9:25:43,dst=1a:6b:2d:47:f3:43),eth_type(0x0800),ipv4(frag=no),
packets:7, bytes:686, used:0.430s, actions:1

In vswitch.log I see messages warning received packet on unassociated
datapath port 2

*2017-12-08T11:30:00.598Z|00093|dpif(handler6)|DBG|system at ovs-system: miss
upcall:*
recirc_id(0),dp_hash(0),skb_priority(0),tunnel(src=192.168.222.204,dst=192.168.222.205,ttl=64,flags(0)),in_port(2),skb_mark(0),ct_state(0),ct_mark(0),eth(src=ee:9f:69:e6:40:4f,dst=33:33:00:00:00:16),eth_type(0x86dd),ipv6(src=fe80::ec9f:69ff:fee6:404f,dst=ff02::16,label=0,proto=58,tclass=0,hlimit=1,frag=no),
        icmpv6(type=143,code=0)
icmp6,vlan_tci=0x0000,dl_src=ee:9f:69:e6:40:4f,dl_dst=33:33:00:00:00:16,ipv6_src=fe80::ec9f:69ff:fee6:404f,ipv6_dst=ff02::16,ipv6_label=0x00000,nw_tos=0,nw_ecn=0,nw_ttl=1,icmp_type=143,icmp_code=0,nd_target=::,nd_sll=00:00:00:00:00:00,nd_tll=00:00:00:00:00:00
icmp6_csum:94ca

*2017-12-08T11:30:00.598Z|00094|tunnel(handler6)|WARN|receive tunnel port
not found *(icmp6,tun_src=192.168.222.204,tun_dst=192.168.222.205,tun_ipv6_src=::,tun_ipv6_dst=::,tun_gbp_id=0,tun_gbp_flags=0,tun_tos=0,tun_ttl=64,tun_flags=0,in_port=2,vlan_tci=0x0000,dl_src=ee:9f:69:e6:40:4f,dl_dst=33:33:00:00:00:16,

ipv6_src=fe80::ec9f:69ff:fee6:404f,ipv6_dst=ff02::16,ipv6_label=0x00000,nw_tos=0,nw_ecn=0,nw_ttl=1,icmp_type=143,icmp_code=0,nd_target=::,nd_sll=00:00:00:00:00:00,nd_tll=00:00:00:00:00:00)

*2017-12-08T11:30:00.598Z|00095|netlink_socket(handler6)|DBG|nl_sock_transact_multiple__
(No error information): nl(len:212, type=23(ovs_flow),
flags=401[REQUEST][ATOMIC], seq=52, pid=2530427498,genl(cmd=1,version=1)*

*2017-12-08T11:30:00.598Z|00096|dpif(handler6)|DBG|system at ovs-system:
put[create] ufid:f9c9f3d5-72ae-4e10-b832-389d0a452e58 *
recirc_id(0),dp_hash(0),skb_priority(0),tunnel(src=192.168.222.204,dst=192.168.222.205,ttl=64,flags(0)),in_port(2),skb_mark(0),ct_state(0),ct_mark(0),eth(src=ee:9f:69:e6:40:4f,dst=33:33:00:00:00:16),eth_type(0x86dd),ipv6(src=fe80::ec9f:69ff:fee6:404f,dst=ff02::16,label=0,proto=58,tclass=0,hlimit=1,frag=no),icmpv6(type=143,code=0)

*2017-12-08T11:30:00.599Z|00097|ofproto_dpif_upcall(handler6)|INFO|received
packet on unassociated datapath port 2*

Do you guys have any idea what else should I look, to troubleshoot this?
I would really appreciate ANY guidance.

Thanks a lot
JM

-- 

*José Miguel Guzmán*Senior Network Consultant
Latin America & Caribbean
  +1 (650) 248-2490 <+16502482490>
  +56 (9) 9064-2780 <+56990642780>
  jmguzman at whitestack.com
  jmguzmanc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20171208/fef88553/attachment-0001.html>