[vpp-dev] vpp19.08 ipsec issue
Dear VPP Team, I'm trying to config ipsec tunnel in vpp19.08. The configuration of 'ikev2' and 'create ipsec tunnel ...' both works fine, but it's difficult for me to config ipsec tunnel via 'ipsec sa...'. There are a lot of issue about ipsec in vpp-dev mail-list, I still not find the right answer. My test topology is as follow: The configuration of each device are as follows: user1: ipv4 address: 100.0.0.3/24 gateway address: 100.0.0.1 vpp1: # basic network set interface state GigabitEthernet2/0/0 up set interface state GigabitEthernet2/1/0 up set interface ip address GigabitEthernet2/0/0 100.0.0.1/24 set interface ip address GigabitEthernet2/1/0 192.168.1.1/24 set interface promiscuous on GigabitEthernet2/0/0 set interface promiscuous on GigabitEthernet2/1/0 # ispec configuration ipsec sa add 10 spi 1001 esp crypto-key 2b7e151628aed2a6abf7158809cf4f3d crypto-alg aes-cbc-128 tunnel-src 192.168.1.1 tunnel-dst 192.168.1.2 ipsec sa add 20 spi 1000 esp crypto-key 2b7e151628aed2a6abf7158809cf4f3d crypto-alg aes-cbc-128 tunnel-src 192.168.1.2 tunnel-dst 192.168.1.1 ipsec spd add 1 set interface ipsec spd GigabitEthernet2/1/0 1 ipsec policy add spd 1 inbound priority 100 protocol 50 action bypass ipsec policy add spd 1 outbound priority 100 protocol 50 action bypass ipsec policy add spd 1 inbound priority 10 action protect sa 20 local-ip-range 100.0.0.3 - 100.0.0.3 remote-ip-range 172.168.1.3 - 172.168.1.3 ipsec policy add spd 1 outbound priority 20 action protect sa 10 local-ip-range 100.0.0.3 - 100.0.0.3 remote-ip-range 172.168.1.3 - 172.168.1.3 ip route add 172.168.1.0/24 via 192.168.1.2 GigabitEthernet2/1/0 vpp2: # basic network set interface state GigabitEthernet2/1/0 up set interface state GigabitEthernet2/2/0 up set interface ip address GigabitEthernet2/1/0 172.168.1.1/24 set interface ip address GigabitEthernet2/2/0 192.168.1.2/24 set interface promiscuous on GigabitEthernet2/1/0 set interface promiscuous on GigabitEthernet2/2/0 # ipsec configuration ipsec sa add 10 spi 1001 esp crypto-key 2b7e151628aed2a6abf7158809cf4f3d crypto-alg aes-cbc-128 tunnel-src 192.168.1.1 tunnel-dst 192.168.1.2 ipsec sa add 20 spi 1000 esp crypto-key 2b7e151628aed2a6abf7158809cf4f3d crypto-alg aes-cbc-128 tunnel-src 192.168.1.2 tunnel-dst 192.168.1.1 ipsec spd add 1 set interface ipsec spd GigabitEthernet2/2/0 1 ipsec policy add spd 1 inbound priority 100 protocol 50 action bypass ipsec policy add spd 1 outbound priority 100 protocol 50 action bypass ipsec policy add spd 1 inbound priority 10 action protect sa 10 local-ip-range 172.168.1.3 - 172.168.1.3 remote-ip-range 100.0.0.3 - 100.0.0.3 ipsec policy add spd 1 outbound priority 20 action protect sa 20 local-ip-range 172.168.1.3 - 172.168.1.3 remote-ip-range 100.0.0.3 - 100.0.0.3 ip route add 100.0.0.0/24 via 192.168.1.1 GigabitEthernet2/2/0 user2: ipv4 address: 172.168.1.3/24 gateway address: 172.168.1.1 After configuration, I tried ping from user1 to user2, the packet dropped by vpp1, here is the trace info: DBGvpp# show trace --- Start of thread 0 vpp_main --- No packets in trace buffer --- Start of thread 1 vpp_wk_0 --- Packet 1 00:08:35:264577: dpdk-input GigabitEthernet2/0/0 rx queue 0 buffer 0x9e330: current data 0, length 98, buffer-pool 0, ref-count 1, totlen-nifb 0, trace handle 0x100 ext-hdr-valid l4-cksum-computed l4-cksum-correct PKT MBUF: port 0, nb_segs 1, pkt_len 98 buf_len 2176, data_len 98, ol_flags 0x0, data_off 128, phys_addr 0x7298cc80 packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 rss 0x0 fdir.hi 0x0 fdir.lo 0x0 IP4: 00:50:56:aa:70:e3 -> 00:50:56:aa:53:75 ICMP: 100.0.0.3 -> 172.168.1.3 tos 0x00, ttl 64, length 84, checksum 0x15f0 fragment id 0x130b, flags DONT_FRAGMENT ICMP echo_request checksum 0x5609 00:08:35:264631: ethernet-input frame: flags 0x3, hw-if-index 1, sw-if-index 1 IP4: 00:50:56:aa:70:e3 -> 00:50:56:aa:53:75 00:08:35:264650: ip4-input-no-checksum ICMP: 100.0.0.3 -> 172.168.1.3 tos 0x00, ttl 64, length 84, checksum 0x15f0 fragment id 0x130b, flags DONT_FRAGMENT ICMP echo_request checksum 0x5609 00:08:35:264673: ip4-lookup fib 0 dpo-idx 2 flow hash: 0x ICMP: 100.0.0.3 -> 172.168.1.3 tos 0x00, ttl 64, length 84, checksum 0x15f0 fragment id 0x130b, flags DONT_FRAGMENT ICMP echo_request checksum 0x5609 00:08:35:264694: ip4-rewrite tx_sw_if_index 2 dpo-idx 2 : ipv4 via 192.168.1.2 GigabitEthernet2/1/0: mtu:9000 000c29c781b0005056aa5d190800 flow hash: 0x : 000c29c781b0005056aa5d1908004554130b40003f0116f06403aca8 0020: 01030800560911580013c609ee5d12510b001011 00:08:35:264701: ipsec4-output-feature spd 1 policy 3 00:08:35:264711: esp4-encrypt esp: sa-index 0 spi 1001 (0x03e9) seq 19 sa-seq-hi 0 crypto aes-cbc-128 integrity none 00:08:35:264731: ip4-load-balance fi
Re: [vpp-dev] vpp19.08 ipsec issue
From: Terry Date: Monday 6 January 2020 at 23:51 To: "Neale Ranns (nranns)" Cc: "vpp-dev@lists.fd.io" Subject: Re:Re:Re: [vpp-dev] vpp19.08 ipsec issue [trim] And when I ping 192.168.1.2 from 100.0.0.3(user1), the TRACE packet information is as follows: Packet 1 00:38:45:983763: handoff_trace HANDED-OFF: from thread 1 trace index 0 00:38:45:983763: nat44-in2out NAT44_IN2OUT_FAST_PATH: sw_if_index 1, next index 3, session -1 00:38:45:983767: nat44-in2out-slowpath NAT44_IN2OUT_SLOW_PATH: sw_if_index 1, next index 0, session 6 00:38:45:983772: ip4-lookup fib 0 dpo-idx 3 flow hash: 0x ICMP: 192.168.1.1 -> 192.168.1.2 which SPD policy does/should this packet match ? /neale tos 0x00, ttl 64, length 84, checksum 0x080c fragment id 0xaf49, flags DONT_FRAGMENT ICMP echo_request checksum 0x8943 00:38:45:983775: ip4-rewrite tx_sw_if_index 2 dpo-idx 3 : ipv4 via 192.168.1.2 GigabitEthernet2/1/0: mtu:9000 000c29f77626000c29347e990800 flow hash: 0x : 000c29f77626000c29347e9908004554af4940003f01090cc0a80101c0a8 0020: 010208008943ad4e00095427135e8f0c0c001011 00:38:45:983778: ipsec4-output-feature spd 1 policy -1 00:38:45:983780: error-drop rx:GigabitEthernet2/0/0 00:38:45:983783: drop dpdk-input: no error Packet 2 00:38:47:007175: handoff_trace HANDED-OFF: from thread 1 trace index 1 00:38:47:007175: nat44-in2out NAT44_IN2OUT_FAST_PATH: sw_if_index 1, next index 3, session -1 00:38:47:007184: nat44-in2out-slowpath NAT44_IN2OUT_SLOW_PATH: sw_if_index 1, next index 0, session 6 00:38:47:007193: ip4-lookup fib 0 dpo-idx 3 flow hash: 0x ICMP: 192.168.1.1 -> 192.168.1.2 tos 0x00, ttl 64, length 84, checksum 0x07f5 fragment id 0xaf60, flags DONT_FRAGMENT ICMP echo_request checksum 0xc1e4 00:38:47:007197: ip4-rewrite tx_sw_if_index 2 dpo-idx 3 : ipv4 via 192.168.1.2 GigabitEthernet2/1/0: mtu:9000 000c29f77626000c29347e990800 flow hash: 0x : 000c29f77626000c29347e9908004554af6040003f0108f5c0a80101c0a8 0020: 01020800c1e4ad4e000a5527135e556a0c001011 00:38:47:007202: ipsec4-output-feature spd 1 policy -1 00:38:47:007206: error-drop rx:GigabitEthernet2/0/0 00:38:47:007209: drop dpdk-input: no error It looks like there are no rules for the traffic get throuth. When I config this command: # set interface ipsec spd GigabitEthernet2/1/0 1 All the packets can not get throuth GigabitEthernet2/1/0 interface. How can I config the IPSec policy to only protect the IPSec traffic and leave other traffic to the normal forwarding? In general, the user1 can access user2 with IPSec tunnel and can also access the public network with NAT in VPP1. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15067): https://lists.fd.io/g/vpp-dev/message/15067 Mute This Topic: https://lists.fd.io/mt/67970551/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] vpp19.08 ipsec issue
From: Terry Date: Tuesday 7 January 2020 at 13:12 To: "Neale Ranns (nranns)" Cc: "vpp-dev@lists.fd.io" Subject: Re:Re: [vpp-dev] vpp19.08 ipsec issue Hi Neale, My understanding is that the interface GigabitEthernet2/1/0 should only protect traffic from 100.0.0.0/24 and 172.168.1.0/24 and let other traffic getting throuth. # ipsec policy add spd 1 inbound priority 10 action protect sa 20 local-ip-range 100.0.0.1 - 100.0.0.3 remote-ip-range 172.168.1.1 - 172.168.1.3 # ipsec policy add spd 1 outbound priority 10 action protect sa 10 local-ip-range 100.0.0.1 - 100.0.0.3 remote-ip-range 172.168.1.1 - 172.168.1.3 These two lines define the rules to pretect 100.0.0.0/24 and 172.168.1.0/24 with SA 10 and and SA 20. # ipsec policy add spd 1 inbound priority 100 protocol 50 action bypass local-ip-range 0.0.0.0 - 255.255.255.255 remote-ip-range 0.0.0.0 - 255.255.255.255 # ipsec policy add spd 1 outbound priority 100 protocol 50 action bypass local-ip-range 0.0.0.0 - 255.255.255.255 remote-ip-range 0.0.0.0 - 255.255.255.255 These two lines define the rules to let all ESP traffic get throuth. The packet TRACE information shows that there are no rules for other traffic to get throuth. There are four action for IPSec policy: bypass, discard, resolve, protect In this scene, if I want the traffic to access public network, I think the action should be BYPASS, and the rule form should be like follows: # ipsec policy add spd 1 outbound priority 90 protocol 0 action bypass local-ip-range 0.0.0.0 - 255.255.255.255 remote-ip-range 0.0.0.0 - 255.255.255.255 That’s correct. The ‘default’ action, in the absence of a hit in the SPD, is to drop. When I add the rule for VPP1 and VPP2, user1 and user2 can ping each other. But the tunnel is still not working. The VPP1 trace information is as follows(user1 ping user 2): vpp# show trace --- Start of thread 0 vpp_main --- No packets in trace buffer --- Start of thread 1 vpp_wk_0 --- Packet 1 14:10:17:029929: dpdk-input GigabitEthernet2/0/0 rx queue 0 buffer 0x9829a: current data 0, length 98, buffer-pool 0, ref-count 1, totlen-nifb 0, trace handle 0x100 ext-hdr-valid l4-cksum-computed l4-cksum-correct PKT MBUF: port 0, nb_segs 1, pkt_len 98 buf_len 2176, data_len 98, ol_flags 0x0, data_off 128, phys_addr 0x2f40a700 packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 rss 0x0 fdir.hi 0x0 fdir.lo 0x0 IP4: 00:0c:29:70:bd:60 -> 00:0c:29:34:7e:8f ICMP: 100.0.0.3 -> 172.168.1.3 tos 0x00, ttl 64, length 84, checksum 0x685b fragment id 0xc09f, flags DONT_FRAGMENT ICMP echo_request checksum 0xe0b8 14:10:17:029953: ethernet-input frame: flags 0x3, hw-if-index 1, sw-if-index 1 IP4: 00:0c:29:70:bd:60 -> 00:0c:29:34:7e:8f 14:10:17:029958: ip4-input-no-checksum ICMP: 100.0.0.3 -> 172.168.1.3 tos 0x00, ttl 64, length 84, checksum 0x685b fragment id 0xc09f, flags DONT_FRAGMENT ICMP echo_request checksum 0xe0b8 14:10:17:029961: nat44-in2out-worker-handoff NAT44_IN2OUT_WORKER_HANDOFF : next-worker 2 trace index 0 Packet 2 14:10:18:055696: dpdk-input GigabitEthernet2/0/0 rx queue 0 buffer 0x982e8: current data 0, length 98, buffer-pool 0, ref-count 1, totlen-nifb 0, trace han dle 0x101 ext-hdr-valid l4-cksum-computed l4-cksum-correct PKT MBUF: port 0, nb_segs 1, pkt_len 98 buf_len 2176, data_len 98, ol_flags 0x0, data_off 128, phys_addr 0x2f40ba80 packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 rss 0x0 fdir.hi 0x0 fdir.lo 0x0 IP4: 00:0c:29:70:bd:60 -> 00:0c:29:34:7e:8f ICMP: 100.0.0.3 -> 172.168.1.3 tos 0x00, ttl 64, length 84, checksum 0x684e fragment id 0xc0ac, flags DONT_FRAGMENT ICMP echo_request checksum 0xe650 14:10:18:055719: ethernet-input frame: flags 0x3, hw-if-index 1, sw-if-index 1 IP4: 00:0c:29:70:bd:60 -> 00:0c:29:34:7e:8f 14:10:18:055723: ip4-input-no-checksum ICMP: 100.0.0.3 -> 172.168.1.3 tos 0x00, ttl 64, length 84, checksum 0x684e fragment id 0xc0ac, flags DONT_FRAGMENT ICMP echo_request checksum 0xe650 14:10:18:055726: nat44-in2out-worker-handoff NAT44_IN2OUT_WORKER_HANDOFF : next-worker 2 trace index 1 --- Start of thread 2 vpp_wk_1 --- Packet 1 14:10:17:029967: handoff_trace HANDED-OFF: from thread 1 trace index 0 14:10:17:029967: nat44-in2out NAT44_IN2OUT_FAST_PATH: sw_if_index 1, next index 3, session -1 14:10:17:029971: nat44-in2out-slowpath NAT44_IN2OUT_SLOW_PATH: sw_if_index 1, next index 0, session 12 14:10:17:029976: ip4-lookup fib 0 dpo-idx 5 flow hash: 0x ICMP: 192.168.1.1 -> 172.168.1.3 tos 0x00, ttl 64, length 84, checksum 0x0ab5 fragment id 0xc09f, flags DONT_FRAGMENT ICMP echo_request checksum 0x2123 14:10:17:029979: ip4-arp ICMP: 192.168.1.1 -> 172.168.1.3
