Bug 219117 - security/ipsec-tools - Patch for PR 217131 breaks roadwarrior setup with NATT and FreeBSD 10.3
Summary: security/ipsec-tools - Patch for PR 217131 breaks roadwarrior setup with NATT...
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Eugene Grosbein
URL:
Keywords: needs-patch
Depends on:
Blocks:
 
Reported: 2017-05-07 13:56 UTC by freebsdlists
Modified: 2017-10-01 19:56 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (vanhu)


Attachments
racoon.conf from VPN gateway (996 bytes, text/plain)
2017-05-07 13:56 UTC, freebsdlists
no flags Details
ipsec-tools build options (1.01 KB, text/plain)
2017-06-22 13:17 UTC, freebsdlists
no flags Details
racoon debug log from working version (128.98 KB, text/plain)
2017-06-22 13:18 UTC, freebsdlists
no flags Details
racoon debug log from broken version (128.98 KB, text/plain)
2017-06-22 13:19 UTC, freebsdlists
no flags Details
Kernel config (14.68 KB, text/plain)
2017-06-22 13:20 UTC, freebsdlists
no flags Details
Correct racoon debug log from broken version (138.52 KB, text/plain)
2017-06-22 14:30 UTC, freebsdlists
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description freebsdlists 2017-05-07 13:56:07 UTC
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.
Comment 1 Eugene Grosbein freebsd_committer freebsd_triage 2017-06-19 20:41:53 UTC
Take is as I commited this change.
Comment 2 Eugene Grosbein freebsd_committer freebsd_triage 2017-06-19 20:56:56 UTC
(In reply to freebsdlists from comment #0)

Please share options you use to build the port.
Comment 3 Andrey V. Elsukov freebsd_committer freebsd_triage 2017-06-20 05:10:14 UTC
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.
Comment 4 freebsdlists 2017-06-22 13:17:49 UTC
Created attachment 183707 [details]
ipsec-tools build options
Comment 5 freebsdlists 2017-06-22 13:18:54 UTC
Created attachment 183708 [details]
racoon debug log from working version
Comment 6 freebsdlists 2017-06-22 13:19:43 UTC
Created attachment 183709 [details]
racoon debug log from broken version
Comment 7 freebsdlists 2017-06-22 13:20:27 UTC
Created attachment 183710 [details]
Kernel config
Comment 8 freebsdlists 2017-06-22 13:23:33 UTC
(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.
Comment 9 Andrey V. Elsukov freebsd_committer freebsd_triage 2017-06-22 14:00:30 UTC
It seems you added the same log for both working and broken.
Comment 10 freebsdlists 2017-06-22 14:30:54 UTC
Created attachment 183712 [details]
Correct racoon debug log from broken version
Comment 11 Andrey V. Elsukov freebsd_committer freebsd_triage 2017-06-23 07:24:52 UTC
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?
Comment 12 freebsdlists 2017-06-23 14:16:29 UTC
(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'.
Comment 13 Andrey V. Elsukov freebsd_committer freebsd_triage 2017-06-23 14:56:46 UTC
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.
Comment 14 freebsdlists 2017-06-23 15:17:24 UTC
(In reply to Andrey V. Elsukov from comment #13)

Yes, I can confirm that removing that chunk does indeed solve the issue.
Comment 15 Eugene Grosbein freebsd_committer freebsd_triage 2017-10-01 19:56:02 UTC
Change this from "In Progress" to "Open" as we still have no solution to this.