Created attachment 182359 [details] racoon.conf from VPN gateway The patch applied in SVN rev 438782 breaks NATT on FreeBSD 10.3 when using the Shrew Soft VPN client. After backing out SVN rev 438782 NATT starts working again. With rev 438782 applied the VPN client connects and the tunnel comes up, however no traffic is passing through the VPN gateway. A tcpdump on enc0 shows that packets from the client passes enc0 in the VPN gateway but they never shows up on the inside interface on the gateway. Relevant parts of the racoon.conf on the VPN gateway is attached.
Take is as I commited this change.
(In reply to freebsdlists from comment #0) Please share options you use to build the port.
Do you have some patches to the kernel that add NAT-T support? The vanilla kernel should not be affected by this change, because SADB_X_EXT_NAT_T_OA[IR] messages are not used by the kernel in any way. If you have applied some patches to the kernel, please add them to this PR. Also it would be interesting to see the debug logs from racoon when it worked, and when it failed to work.
Created attachment 183707 [details] ipsec-tools build options
Created attachment 183708 [details] racoon debug log from working version
Created attachment 183709 [details] racoon debug log from broken version
Created attachment 183710 [details] Kernel config
(In reply to Andrey V. Elsukov from comment #3) Tested again with FreeBSD 10.3-RELEASE-p19 #5 r320191. The kernel config file used to build the kernel is attached. There are no additional patches to the kernel.
It seems you added the same log for both working and broken.
Created attachment 183712 [details] Correct racoon debug log from broken version
From the working log I see that you have some security policies configured before racoon start. In the broken log there is no such policies. I think you have these policies preinstalled: 2017-06-22 15:04:51: DEBUG: sub:0x7fffffffe4b8: 0.0.0.0/0[0] 172.20.1.254/32[0] proto=any dir=out 2017-06-22 15:04:51: DEBUG: db :0x802c5c490: 172.20.1.254/32[0] 0.0.0.0/0[0] proto=any dir=in But for broken case, due to the discussed patch these policies are generated by racoon: 2017-06-22 15:05:12: DEBUG: use NAT address 172.20.1.254[0] as src 2017-06-22 15:05:12: DEBUG: db :0x802c5c490: 172.20.1.254/32[0] 0.0.0.0/0[0] proto=any dir=in 2017-06-22 15:05:12: DEBUG: sub:0x7fffffffe0a8: 0.0.0.0/0[0] 172.20.1.254/32[0] proto=any dir=out Since connection successfully established, the problem should be somewhere in the obtained policies or associations. Can you show the output of `setkey -D` and `setkey -DP` from both cases when tunnel is already established? Also, if I understand correctly, you see ESP-in-UDP packets on the gateway, and see ESP packets in the enc0 on the gateway, but after decryption packets are lost. Am I right? Can you look at the `netstat -s | grep sum` on the gateway? Do some counters grow in the time when you doing test?
(In reply to Andrey V. Elsukov from comment #11) No, there shouldn't be any policies preinstalled. When running setkey -D and setkey -DP prior to connecting the VPN client shows no policies at all on both the working and the broken version. Running setkey -D/setkey -DP on the working version with an established tunnel gives the following output: root@vpngw:/var/log # setkey -DP 10.10.0.1[any] 0.0.0.0/0[any] any in ipsec esp/tunnel/172.20.1.254-172.20.2.3/require created: Jun 23 15:14:19 2017 lastused: Jun 23 15:14:19 2017 lifetime: 3600(s) validtime: 0(s) spid=5 seq=1 pid=5159 refcnt=1 0.0.0.0/0[any] 10.10.0.1[any] any out ipsec esp/tunnel/172.20.2.3-172.20.1.254/require created: Jun 23 15:14:19 2017 lastused: Jun 23 15:14:24 2017 lifetime: 3600(s) validtime: 0(s) spid=6 seq=0 pid=5159 refcnt=1 root@vpngw:/var/log # setkey -D 172.20.2.3 172.20.1.254 esp mode=tunnel spi=3479035284(0xcf5ddd94) reqid=0(0x00000000) E: rijndael-cbc b7991866 9d2d532e 0e4e68a4 2713168d b33164ae 36d9e606 bf393d7f 188191db A: hmac-sha2-256 8d7cc6ec 5e96f3da b182dfc0 f7bd3bf5 1b481a38 caa9ccbd 38f9afd8 9d2fc702 seq=0x0000000d replay=4 flags=0x00000000 state=mature created: Jun 23 15:14:19 2017 current: Jun 23 15:14:40 2017 diff: 21(s) hard: 3600(s) soft: 2880(s) last: Jun 23 15:14:37 2017 hard: 0(s) soft: 0(s) current: 2940(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 13 hard: 0 soft: 0 sadb_seq=1 pid=5160 refcnt=2 172.20.1.254 172.20.2.3 esp mode=tunnel spi=45914926(0x02bc9b2e) reqid=0(0x00000000) E: rijndael-cbc dc3102b3 5c48aff4 f0ad342f 12b77ef8 4df264e1 3003f975 cd70cb03 6b6242f8 A: hmac-sha2-256 2afb52d5 ee26ca35 18663b28 f55f5b96 daee954b 28ca0419 4130e260 bdb6d882 seq=0x00000028 replay=4 flags=0x00000000 state=mature created: Jun 23 15:14:19 2017 current: Jun 23 15:14:40 2017 diff: 21(s) hard: 3600(s) soft: 2880(s) last: Jun 23 15:14:37 2017 hard: 0(s) soft: 0(s) current: 2350(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 40 hard: 0 soft: 0 sadb_seq=0 pid=5160 refcnt=1 Running setkey -D/setkey -DP on the broken version with an established tunnel gives the following output: root@vpngw:~ # setkey -DP 172.20.1.254[any] 0.0.0.0/0[any] any in ipsec esp/tunnel/172.20.1.254-172.20.2.3/require created: Jun 23 15:20:46 2017 lastused: Jun 23 15:20:46 2017 lifetime: 3600(s) validtime: 0(s) spid=1 seq=1 pid=815 refcnt=1 0.0.0.0/0[any] 172.20.1.254[any] any out ipsec esp/tunnel/172.20.2.3-172.20.1.254/require created: Jun 23 15:20:46 2017 lastused: Jun 23 15:20:46 2017 lifetime: 3600(s) validtime: 0(s) spid=2 seq=0 pid=815 refcnt=1 root@vpngw:~ # setkey -D 172.20.2.3 172.20.1.254 esp mode=tunnel spi=669665947(0x27ea4a9b) reqid=0(0x00000000) E: rijndael-cbc bbaa845f 73583021 963b49dc daf8b6ea 980be021 8f949858 d27097b9 160387f6 A: hmac-sha2-256 110877a0 e700eb07 557287d0 0d053f4d f7f58c44 409a8ccf d28c5cf1 26f4a15f seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jun 23 15:20:46 2017 current: Jun 23 15:21:19 2017 diff: 33(s) hard: 3600(s) soft: 2880(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=1 pid=816 refcnt=1 172.20.1.254 172.20.2.3 esp mode=tunnel spi=120225482(0x072a7eca) reqid=0(0x00000000) E: rijndael-cbc 953f124c 0e9f9ad6 666a9af9 1595080f 0f8ddaa7 db29cadd 479a6d89 4b07d59d A: hmac-sha2-256 544f7db7 646e84e6 78123ab3 6878c5ef 92561590 06ea3123 bd70b4f5 fd28ef5f seq=0x0000004b replay=4 flags=0x00000000 state=mature created: Jun 23 15:20:46 2017 current: Jun 23 15:21:19 2017 diff: 33(s) hard: 3600(s) soft: 2880(s) last: Jun 23 15:21:18 2017 hard: 0(s) soft: 0(s) current: 5413(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 75 hard: 0 soft: 0 sadb_seq=0 pid=816 refcnt=1 I see ESP-in-UDP packets on the outside interface of the gateway, decrypted packets on enc0 as well as on the inside interface of the gateway. I also see reply packets on the inside interface of the gateway but not on enc0 nor any ESP-in-UDP reply packets on the outside interface of the gateway. I do however see non encrypted reply packets on the outside interface of the gateway. 'netstat -s | grep sum' shows that the only counter that increases is 'with no checksum'.
So, it looks like the problem is due to the chunk for "src/racoon/isakmp_quick.c". I think if you just remove this chunk from natt.diff it will work. But probably it will not work for transport mode. I don't see the easy way to determine the mode in this place.
(In reply to Andrey V. Elsukov from comment #13) Yes, I can confirm that removing that chunk does indeed solve the issue.
Change this from "In Progress" to "Open" as we still have no solution to this.