From: Terry <[email protected]>
Date: Tuesday 7 January 2020 at 13:12
To: "Neale Ranns (nranns)" <[email protected]>
Cc: "[email protected]" <[email protected]>
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 0x1000000
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 0x1000001
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: 0x00000000
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
tos 0x00, ttl 64, length 84, checksum 0x0ab5
fragment id 0xc09f, flags DONT_FRAGMENT
ICMP echo_request checksum 0x2123
14:10:17:029982: GigabitEthernet2/1/0-output
GigabitEthernet2/1/0
ARP: 00:0c:29:34:7e:99 -> ff:ff:ff:ff:ff:ff
request, type ethernet/IP4, address size 6/4
00:0c:29:34:7e:99/192.168.1.1 -> 00:00:00:00:00:00/192.168.2.2
14:10:17:029984: error-drop
rx:GigabitEthernet2/0/0
14:10:17:029985: GigabitEthernet2/1/0-tx
GigabitEthernet2/1/0 tx queue 2
buffer 0x98273: current data -14, length 42, buffer-pool 0, ref-count 1,
trace handle 0x2000000
PKT MBUF: port 65535, nb_segs 1, pkt_len 42
buf_len 2176, data_len 42, ol_flags 0x0, data_off 114, phys_addr 0x2f409d40
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
ARP: 00:0c:29:34:7e:99 -> ff:ff:ff:ff:ff:ff
request, type ethernet/IP4, address size 6/4
00:0c:29:34:7e:99/192.168.1.1 -> 00:00:00:00:00:00/192.168.2.2
14:10:17:029996: drop
ip4-arp: ARP requests sent
Packet 2
14:10:18:057039: handoff_trace
HANDED-OFF: from thread 1 trace index 1
14:10:18:057039: nat44-in2out
NAT44_IN2OUT_FAST_PATH: sw_if_index 1, next index 3, session -1
14:10:18:057044: nat44-in2out-slowpath
NAT44_IN2OUT_SLOW_PATH: sw_if_index 1, next index 0, session 12
14:10:18:057048: ip4-lookup
fib 0 dpo-idx 5 flow hash: 0x00000000
ICMP: 192.168.1.1 -> 172.168.1.3
tos 0x00, ttl 64, length 84, checksum 0x0aa8
fragment id 0xc0ac, flags DONT_FRAGMENT
ICMP echo_request checksum 0x26bb
14:10:18:057051: ip4-arp
ICMP: 192.168.1.1 -> 172.168.1.3
tos 0x00, ttl 64, length 84, checksum 0x0aa8
fragment id 0xc0ac, flags DONT_FRAGMENT
ICMP echo_request checksum 0x26bb
14:10:18:057054: GigabitEthernet2/1/0-output
GigabitEthernet2/1/0
ARP: 00:0c:29:34:7e:99 -> ff:ff:ff:ff:ff:ff
request, type ethernet/IP4, address size 6/4
00:0c:29:34:7e:99/192.168.1.1 -> 00:00:00:00:00:00/192.168.2.2
14:10:18:057056: error-drop
rx:GigabitEthernet2/0/0
14:10:18:057058: GigabitEthernet2/1/0-tx
GigabitEthernet2/1/0 tx queue 2
buffer 0x9829a: current data -14, length 42, buffer-pool 0, ref-count 1,
trace handle 0x2000001
PKT MBUF: port 65535, nb_segs 1, pkt_len 42
buf_len 2176, data_len 42, ol_flags 0x0, data_off 114, 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
ARP: 00:0c:29:34:7e:99 -> ff:ff:ff:ff:ff:ff
request, type ethernet/IP4, address size 6/4
00:0c:29:34:7e:99/192.168.1.1 -> 00:00:00:00:00:00/192.168.2.2
14:10:18:058737: drop
ip4-arp: ARP requests sent
The ARP request is dropped.
The ARP request was sent. If the other end dropped it, it’s probably because
the sender in not on the same subnet. Your config has one end as a /22 the
other as a /24.
/neale
Best regards,
Terry
在 2020-01-07 05:30:14，"Neale Ranns (nranns)" <[email protected]> 写道：
From: Terry <[email protected]>
Date: Monday 6 January 2020 at 23:51
To: "Neale Ranns (nranns)" <[email protected]>
Cc: "[email protected]" <[email protected]>
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: 0x00000000
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: 0x00000000
00000000: 000c29f77626000c29347e99080045000054af4940003f01090cc0a80101c0a8
00000020: 010208008943ad4e00095427135e000000008f0c0c00000000001011
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: 0x00000000
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: 0x00000000
00000000: 000c29f77626000c29347e99080045000054af6040003f0108f5c0a80101c0a8
00000020: 01020800c1e4ad4e000a5527135e00000000556a0c00000000001011
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 (#15068): https://lists.fd.io/g/vpp-dev/message/15068
Mute This Topic: https://lists.fd.io/mt/67970551/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
