Just for record purposes, here are the configs I figured out on l2 gretap + ipsec transport mode. The other party config is similar with proper changes in ip, mac address and spi. Make sure spi matches. Otherwise, pkt will be punted on the receiving side.
set int state eth0 up set int ip address eth0 10.10.10.11/24 set int promiscuous on eth0 set ip arp eth0 10.10.10.10 24:6e:96:b4:b2:07 set int state eth1 up set int promiscuous on eth1 create gre tunnel src 10.10.10.11 dst 10.10.10.10 teb set int state gre0 up create bridge-domain 1 set interface l2 bridge gre0 1 set interface l2 bridge eth1 1 ipsec spd add 1 set interface ipsec spd eth0 1 ipsec sa add 1 spi 255128 esp crypto-key 0123456789012345678901234567890101234567890123456789012345678901 crypto-alg aes-gcm-256 ipsec sa add 2 spi 255129 esp crypto-key 0123456789012345678901234567890101234567890123456789012345678901 crypto-alg aes-gcm-256 ipsec policy add spd 1 priority 90 inbound action protect sa 2 local-ip-range 10.10.10.11-10.10.10.11 remote-ip-range 10.10.10.10-10.10.10.10 ipsec policy add spd 1 priority 90 outbound action protect sa 1 local-ip-range 10.10.10.11-10.10.10.11 remote-ip-range 10.10.10.10-10.10.10.10 trace add dpdk-input 10 On Tue, Oct 8, 2019 at 3:23 PM Chuan Han via Lists.Fd.Io <chuanhan= google....@lists.fd.io> wrote: > Hi, Neale/vpp experts, > > Can you help check why the receiving side drops all the incoming pkts > because of unknown ip protocol? > > I looked at TestIpsecGreTebIfEsp, but had no clue how it is mapped to cli > commands. > > I am new to vpp. > > Thanks. > Chuan > > On Fri, Oct 4, 2019 at 11:41 AM Chuan Han via Lists.Fd.Io <chuanhan= > google....@lists.fd.io> wrote: > >> Thanks for helping. >> >> I removed spd configs on both sides, but still no luck. I am pinging from >> r230 side. >> >> It seems r230 is able to sending ping pkts over dpdk interface. However, >> on r740 side, gre0 interface drops all of them. See the attached updated >> cfg files and log files for more details. >> >> IPSec: remote:10.10.10.11 spi:255129 (0x0003e499) seq 418 >> 00:06:52:367944: esp4-decrypt-tun >> esp: crypto aes-cbc-128 integrity sha1-96 pkt-seq 418 sa-seq 0 >> sa-seq-hi 0 >> 00:06:52:367948: ip4-input-no-checksum >> GRE: 10.10.10.11 -> 10.10.10.10 >> tos 0x00, ttl 254, length 66, checksum 0x9464 >> fragment id 0x0000 >> GRE teb >> 00:06:52:367948: ip4-not-enabled >> GRE: 10.10.10.11 -> 10.10.10.10 >> tos 0x00, ttl 254, length 66, checksum 0x9464 >> fragment id 0x0000 >> GRE teb >> 00:06:52:367948: error-drop >> rx:gre0 >> 00:06:52:367949: drop >> ip4-input: unknown ip protocol >> >> >> On Fri, Oct 4, 2019 at 8:39 AM Neale Ranns (nranns) <nra...@cisco.com> >> wrote: >> >>> >>> >>> Hi Chuan, >>> >>> >>> >>> Please remove the SPD config. For tunnels all packets that >>> ingress/egress the tunnel are decrypted/encrypted, so no policy is >>> required. The presence of the SPD on the ingress eth0 link could be why >>> it’s not working. >>> >>> Please provide packet traces when you are reporting packet loss >>> problems, it helps us debug. >>> >>> >>> >>> For reference the setup for GRE TEB IPSec can be found in the python UT >>> TestIpsecGreTebIfEsp. >>> >>> >>> >>> Regards, >>> >>> neale >>> >>> >>> >>> >>> >>> *From: *<vpp-dev@lists.fd.io> on behalf of "Chuan Han via Lists.Fd.Io" >>> <chuanhan=google....@lists.fd.io> >>> *Reply to: *"chuan...@google.com" <chuan...@google.com> >>> *Date: *Friday 4 October 2019 at 02:15 >>> *To: *"John Lo (loj)" <l...@cisco.com> >>> *Cc: *"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> >>> *Subject: *Re: [vpp-dev] How to configure l2 gre over ipsec in vpp 19.08 >>> >>> >>> >>> Hi, >>> >>> >>> >>> Thanks for information. >>> >>> >>> >>> I am trying to configure l2 gre over ipsec transport mode. >>> >>> >>> >>> Here are my startup.cfg files. Can you help check if my configuration is >>> correct or not? >>> >>> >>> >>> r230 and r740 are two servers which are directly connected. >>> >>> >>> >>> eth0 is the phy nic. host-veth1 is one endpoint of veth pair. the other >>> end is connected to a network namespace with ip address 172.16.1.2. >>> >>> >>> >>> From the network namespace, I cannot ping the other end 172.16.1.1. >>> >>> >>> >>> On r230, I can see unknown ip protocol errors. >>> >>> vpp# sh errors >>> Count Node Reason >>> 5 null-node blackholed packets >>> 5 ipsec4-output-feature IPSec policy (no match) >>> 1 esp4-decrypt-tun ESP pkts received >>> 1 ipsec4-tun-input good packets received >>> 1 ipsec4-input-feature IPSEC pkts received >>> 1 ip4-input unknown ip protocol >>> 592 gre-encap GRE output packets >>> encapsulated >>> 592 ipsec4-output-feature IPSec policy bypass >>> 592 esp4-encrypt-tun ESP pkts received >>> 592 l2-output L2 output packets >>> 592 l2-learn L2 learn packets >>> 1 l2-learn L2 learn misses >>> 592 l2-input L2 input packets >>> 592 l2-flood L2 flood packets >>> vpp# sh int >>> Name Idx State MTU (L3/IP4/IP6/MPLS) >>> Counter Count >>> eth0 1 up 9000/0/0/0 rx >>> packets 1 >>> rx >>> bytes 166 >>> tx >>> packets 592 >>> tx >>> bytes 88816 >>> >>> drops 5 >>> ip4 >>> 1 >>> >>> rx-error 1 >>> gre0 3 up 9000/0/0/0 >>> drops 1 >>> ip4 >>> 1 >>> host-veth1 2 up 9000/0/0/0 rx >>> packets 592 >>> rx >>> bytes 24892 >>> local0 0 down 0/0/0/0 >>> vpp# sh errors >>> Count Node Reason >>> 5 null-node blackholed packets >>> 5 ipsec4-output-feature IPSec policy (no match) >>> 1 esp4-decrypt-tun ESP pkts received >>> 1 ipsec4-tun-input good packets received >>> 1 ipsec4-input-feature IPSEC pkts received >>> 1 ip4-input unknown ip protocol >>> 592 gre-encap GRE output packets >>> encapsulated >>> 592 ipsec4-output-feature IPSec policy bypass >>> 592 esp4-encrypt-tun ESP pkts received >>> 592 l2-output L2 output packets >>> 592 l2-learn L2 learn packets >>> 1 l2-learn L2 learn misses >>> 592 l2-input L2 input packets >>> 592 l2-flood L2 flood packets >>> vpp# >>> >>> >>> >>> On r740, I see the same errors: >>> >>> >>> >>> vpp# sh int >>> Name Idx State MTU (L3/IP4/IP6/MPLS) >>> Counter Count >>> eth0 1 up 9000/0/0/0 rx >>> packets 592 >>> rx >>> bytes 88816 >>> tx >>> packets 1 >>> tx >>> bytes 166 >>> ip4 >>> 592 >>> gre0 3 up 9000/0/0/0 >>> drops 592 >>> ip4 >>> 592 >>> host-veth1 2 up 9000/0/0/0 rx >>> packets 1 >>> rx >>> bytes 70 >>> local0 0 down 0/0/0/0 >>> vpp# sh errors >>> Count Node Reason >>> 592 esp4-decrypt-tun ESP pkts received >>> 592 ipsec4-tun-input good packets received >>> 592 ipsec4-input-feature IPSEC pkts received >>> 592 ip4-input unknown ip protocol >>> 1 gre-encap GRE output packets >>> encapsulated >>> 1 ipsec4-output-feature IPSec policy bypass >>> 1 esp4-encrypt-tun ESP pkts received >>> 1 l2-output L2 output packets >>> 1 l2-learn L2 learn packets >>> 1 l2-learn L2 learn misses >>> 1 l2-input L2 input packets >>> 1 l2-flood L2 flood packets >>> vpp# >>> >>> >>> >>> On Wed, Oct 2, 2019 at 9:13 AM John Lo (loj) <l...@cisco.com> wrote: >>> >>> To create GRE tunnel in L2 mode, you can add “teb” keyword in the create >>> CLI which makes the GRE tunnel work in transparent ethernet bridging mode: >>> >>> >>> >>> vpp# create gre ? >>> >>> create gre tunnel create gre tunnel src <addr> >>> dst <addr> [instance <n>] [outer-fib-id <fib>] [*teb* | erspan >>> <session-id>] [del] >>> >>> >>> >>> In theory, a GRE tunnel can be configured with IPSec, as described by >>> Neale, irrespective of it being in teb mode or not. Neale, please correct >>> me if it is not the case. >>> >>> >>> >>> Regards, >>> >>> John >>> >>> >>> >>> *From:* vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> *On Behalf Of *Chuan >>> Han via Lists.Fd.Io >>> *Sent:* Wednesday, October 02, 2019 11:32 AM >>> *To:* Neale Ranns (nranns) <nra...@cisco.com> >>> *Cc:* vpp-dev@lists.fd.io >>> *Subject:* Re: [vpp-dev] How to configure l2 gre over ipsec in vpp 19.08 >>> >>> >>> >>> Gre is l3 in this case. Right? This limits the possible use cases. >>> >>> >>> >>> Is there any plan to support l2 gre over ipsec transport mode? It seems >>> vpp 17 support s this feature. Not sure why it is dropped in 19. >>> >>> >>> >>> On Wed, Oct 2, 2019, 12:18 AM Neale Ranns (nranns) <nra...@cisco.com> >>> wrote: >>> >>> >>> Hi Chuan, >>> >>> IPSec and GRE is supported using the tunnel protection mechanism : >>> https://wiki.fd.io/view/VPP/IPSec >>> >>> GRE over IPSec is only support when the SA is in tunnel mode. This means >>> there is a double encap of the IP header ; once by the SA (in tunnel mode) >>> and once by the tunnel itself. (Which has always been the case in VPP). >>> >>> Example config follows : >>> >>> DBGvpp# ipsec sa add 20 spi 200 crypto-key >>> 6541686776336961656264656f6f6579 crypto-alg aes-cbc-128 tunnel-src >>> 10.10.10.10 tunnel-dst 10.10.10.11 >>> DBGvpp# ipsec sa add 30 spi 300 crypto-key >>> 6541686776336961656264656f6f6579 crypto-alg aes-cbc-128 tunnel-src >>> 10.10.10.11 tunnel-dst 10.10.10.10 >>> DBGvpp# create gre tunnel src 10.10.10.10 dst 10.10.10.11 >>> gre0 >>> DBGvpp# ipsec tunnel protect gre0 sa-in 20 sa-out 30 >>> DBGvpp# sh ipsec protect >>> gre0 >>> output-sa: >>> [1] sa 30 (0x1e) spi 300 (0x0000012c) protocol:esp flags:[tunnel ] >>> input-sa: >>> [0] sa 20 (0x14) spi 200 (0x000000c8) protocol:esp flags:[tunnel >>> Protect ] >>> >>> Regards, >>> neale >>> >>> >>> From: <vpp-dev@lists.fd.io> on behalf of "Chuan Han via Lists.Fd.Io" >>> <chuanhan=google....@lists.fd.io> >>> Reply to: "chuan...@google.com" <chuan...@google.com> >>> Date: Wednesday 2 October 2019 at 02:08 >>> To: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> >>> Cc: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> >>> Subject: [vpp-dev] How to configure l2 gre over ipsec in vpp 19.08 >>> >>> Hi, vpp experts, >>> >>> I am trying to configure l2 gre over ipsec. I followed the steps here: >>> https://docs.fd.io/vpp/16.12/ipsec_gre_doc.html >>> >>> I hit the following error: >>> create ipsec: unknown input `gre tunnel src 10.10.10.10 dst...' >>> >>> My vpp version is v19.08.1-release >>> >>> It seems on this version the "create ipsec gre tunnel" command does not >>> work. If so, is there any other way of configuring l2 gre over ipsec in >>> 19.08? >>> >>> Please advise. >>> >>> Thanks. >>> Chuan >>> >>> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> >> View/Reply Online (#14123): https://lists.fd.io/g/vpp-dev/message/14123 >> Mute This Topic: https://lists.fd.io/mt/34364734/1991531 >> Group Owner: vpp-dev+ow...@lists.fd.io >> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [chuan...@google.com] >> -=-=-=-=-=-=-=-=-=-=-=- >> > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#14150): https://lists.fd.io/g/vpp-dev/message/14150 > Mute This Topic: https://lists.fd.io/mt/34364734/1991531 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [chuan...@google.com] > -=-=-=-=-=-=-=-=-=-=-=- >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14467): https://lists.fd.io/g/vpp-dev/message/14467 Mute This Topic: https://lists.fd.io/mt/34364734/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
