XFRM tunnel issue.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi All,

We have tunnel test scenario as below

IPsec tunnel gets created between  
1. Our device    	3000:0000:0000:0000:b25c:daff:fe67:f173
2. Gateway 	3001:0000:0000:0000:0200:10ff:fe10:1161 

There are 2 hosts behind the gateway
1. Host1       3002:0000:0000:0000:0200:10ff:fe10:1280
2. Host2       3002:0000:0000:0000:0200:10ff:fe10:1161

Packet sequence:
1.             Host1                       Sends a ping request
2.             Device                     Sends successful ping response
3.             Host1                       Sends a ping request (fragmented)
4.             Device                     Handles fragmented packets and sends a successful ping response.
5.             Host2                       Sends packet too big request with MTU indicated
6.             Host1                       Sends ping request   
7.             Device                     Fails to send fragmented response, sends ping response.

Issue is with packet number 5.
1.             From IPv6 recv hook, packet comes to XFRM recv hook.
2.             At high level, there seems to be no issue with packet. Hence XFRM state gets allocated to packet. And IPsec peer addresses are assigned in the state properly.
3.             Packet gets decrypted by ESP and then reaches ICMP recv hook.
4.            Again XFRM policy look up is done. This is failing as XFRM policy seems to be invalid. Hence packet gets dropped silently.  

When the packet is received in xfrm_input and assigned a xfrm_state as below
daddr   0000:0000:0000:0000:0000:0000:0000:0000 	dport  0  dport_mask 0  prefixlen_d 0
saddr   0000:0000:0000:0000:0000:0000:0000:0000 	sport  0  sport_mask 0  prefixlen_s 0
family  0   	proto  0  ifindex    0 
daddr  3000:0000:0000:0000:b25c:daff:fe67:f173  spi -1503044001  proto 50 
mark 0 0 
saddr  3001:0000:0000:0000:0200:10ff:fe10:1161 
 
In icmpv6_rcv hook when XFRM policy look up is done
mark    8   	      248 
daddr   0000:0000:0000:0000:0000:0000:0000:0000 	dport  0  dport_mask 255  prefixlen_d 0
saddr   0000:0000:0000:0000:0000:0000:0000:0000 	sport  512  sport_mask 65535  prefixlen_s 0
family  10   	proto  58  ifindex    0 
type    0   	action 0  flags      0  xfrmr_nr    0 priority 20096408 
daddr   0000:0000:0000:0000:0000:0000:0000:0000  spi    0  proto      0 
saddr   0000:0000:0000:0000:0000:0000:0000:0000 	family 0  reqid      0 mode         0 share    0  

We are using the Linux 4.9.180 #71 SMP PREEMPT aarch64 GNU/Linux. Did anyone face this kind of issues? Can you please provide me any inputs?

Thanks and regards,
Jayalakshmi








[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux