[strongSwan] manual bypass policy for client-server architecture using transport mode
Plevin
phlevin at runbox.com
Mon Jul 11 20:03:52 CEST 2016
Hello,
Any pointers on this request are greatly appreciated...
I'm trying to configure a client-server architecture using transport mode and
shared secret auth. By default, all communication will be encrypted, but
there will be a small exception list based on port and protocol. Anything on
the exception list is sent cleartext, the rest is encrypted.
So I tried a simple setup using the test environment, based on
ikev2/host2host-transport, where I attempt to bypass tcp/5001 traffic, but
encrypt everything else:
moon:
> conn %default
> ikelifetime=60m
> keylife=20m
> rekeymargin=3m
> keyingtries=1
> mobike=no
> keyexchange=ikev2
>
> conn client-1
> left=192.168.0.1
> right=192.168.0.2
> leftfirewall=yes
> type=transport
> authby=secret
> auto=add
>
> conn client-1-bypass
> left=192.168.0.1
> right=192.168.0.2
> rightsubnet=192.168.0.2[tcp/5001]
> leftfirewall=yes
> type=passthrough
> authby=secret
> auto=add
sun:
> conn %default
> ikelifetime=60m
> keylife=20m
> rekeymargin=3m
> keyingtries=1
> mobike=no
> keyexchange=ikev2
>
> conn server
> left=192.168.0.2
> leftfirewall=yes
> right=%any
> type=transport
> authby=secret
> auto=add
>
> conn server-bypass
> left=192.168.0.2
> leftsubnet=192.168.0.2[tcp/5001]
> right=%any
> leftfirewall=yes
> type=passthrough
> authby=secret
> auto=add
In short, it doesn't work. All traffic, everything sent from moon, INCLUDING
tcp/5001, as detected via nflog samples. Moon shows the
bypass connection in charon (sun is similar):
> >>> moon: ipsec statusall
>
> No leaks detected, 1 suppressed by whitelist
> Status of IKE charon daemon (strongSwan 5.4.0, Linux 4.2.0, x86_64):
> uptime: 70 seconds, since Jul 11 16:50:38 2016
> malloc: sbrk 1613824, mmap 0, used 1533264, free 80560
> worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
> loaded plugins: charon aes des sha1 sha2 md5 pem pkcs1 gmp random nonce x509 curl revocation hmac xcbc stroke
kernel-netlink socket-default updown
> Listening IP addresses:
> 192.168.0.1
> fec0::1
> 10.1.0.1
> fec1::1
> Connections:
> client-1: 192.168.0.1...192.168.0.2 IKEv2
> client-1: local: [192.168.0.1] uses pre-shared key authentication
> client-1: remote: [192.168.0.2] uses pre-shared key authentication
> client-1: child: dynamic === dynamic TRANSPORT
> client-1-bypass: 192.168.0.1...192.168.0.2 IKEv2
> client-1-bypass: local: [192.168.0.1] uses public key authentication
> client-1-bypass: remote: [192.168.0.2] uses public key authentication
> client-1-bypass: child: dynamic === 192.168.0.2/32[tcp/5001] PASS
> Security Associations (1 up, 0 connecting):
> client-1[1]: ESTABLISHED 70 seconds ago, 192.168.0.1[192.168.0.1]...192.168.0.2[192.168.0.2]
> client-1[1]: IKEv2 SPIs: 84ed7d2dd12991e2_i* b824367052186ce5_r, pre-shared key reauthentication in 52 minutes
> client-1[1]: IKE proposal: AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_3072
> client-1{1}: INSTALLED, TRANSPORT, reqid 1, ESP SPIs: cc2755c5_i c0ec6ec6_o
> client-1{1}: AES_CBC_128/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 13 minutes
> client-1{1}: 192.168.0.1/32 === 192.168.0.2/32
However, moon shows the policies for the bypass as havingtemplates:
> moon:~# ip xfrm policy
> ip xfrm policy
> src 192.168.0.2/32 dst 192.168.0.1/32 proto tcp sport 5001
> dir fwd priority 2816 ptype main
> tmpl src 192.168.0.2 dst 192.168.0.1
> proto esp reqid 2 mode tunnel
> src 192.168.0.2/32 dst 192.168.0.1/32 proto tcp sport 5001
> dir in priority 2816 ptype main
> tmpl src 192.168.0.2 dst 192.168.0.1
> proto esp reqid 2 mode tunnel
> src 192.168.0.1/32 dst 192.168.0.2/32 proto tcp dport 5001
> dir out priority 2816 ptype main
> tmpl src 192.168.0.1 dst 192.168.0.2
> proto esp reqid 2 mode tunnel
> src 192.168.0.2/32 dst 192.168.0.1/32
> dir in priority 2819 ptype main
> tmpl src 0.0.0.0 dst 0.0.0.0
> proto esp reqid 1 mode transport
> src 192.168.0.1/32 dst 192.168.0.2/32
> dir out priority 2819 ptype main
> tmpl src 0.0.0.0 dst 0.0.0.0
> proto esp reqid 1 mode transport
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket in priority 0 ptype main
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket out priority 0 ptype main
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket in priority 0 ptype main
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket out priority 0 ptype main
which creates SAs for the "bypass", so no surprise that the tcp/5001 traffic
is encrypted too:
> moon:~# ip xfrm state
> ip xfrm state
> src 192.168.0.1 dst 192.168.0.2
> proto esp spi 0xcb00e25f reqid 1 mode transport
> replay-window 32
> auth-trunc hmac(sha256) 0x839ea14d6fbfa28c198433b23bea2926271ed09b6afd6ec1e1c362ecf2558e05 128
> enc cbc(aes) 0x0fe599c09755bf3956266f09fda7e01d
> sel src 192.168.0.1/32 dst 192.168.0.2/32
> src 192.168.0.2 dst 192.168.0.1
> proto esp spi 0xcc7307e9 reqid 1 mode transport
> replay-window 32
> auth-trunc hmac(sha256) 0x86f6e022d784c2cf809c4f9700a025584abdfa11e18c04a20d0a95865e62809b 128
> enc cbc(aes) 0x27113998c69fdba3ab6baae003ff0501
> sel src 192.168.0.2/32 dst 192.168.0.1/32
> src 192.168.0.1 dst 192.168.0.2
> proto esp spi 0xc6318982 reqid 2 mode tunnel
> replay-window 32 flag af-unspec
> auth-trunc hmac(sha256) 0xc53e385238df420ba7ab3c8b5d337ed54e54a2e4faf7730b2efdaf941bdc3648 128
> enc cbc(aes) 0xeafb109579c86fe21fb25b1061295eec
> src 192.168.0.2 dst 192.168.0.1
> proto esp spi 0xc1629f74 reqid 2 mode tunnel
> replay-window 32 flag af-unspec
> auth-trunc hmac(sha256) 0x241897c993d33184817e0932f72396c6f3d15aa2f175426a0b7d33caefe5c3e7 128
> enc cbc(aes) 0x60b64dd6ff61e6112ef68f9a40637c9e
I thought that to force a "exception policy," one should install a policy
*without* an associated template. The presence of template is normally a
signal to the kernel to create an SA bundle, and it's absence is a way to
request cleartext transmission.
Finally, I tried to get the bypass to work by removing client-1-bypass and
server-bypass config. Then added my own bypass policies:
moon:
ip xfrm policy add dst 192.168.0.2/32 proto tcp dport 5001 dir out priority 100 ptype main action allow
ip xfrm policy add dst 192.168.0.2/32 proto tcp dport 5001 dir fwd priority 100 ptype main action allow
ip xfrm policy add dst 192.168.0.1/32 proto tcp sport 5001 dir in priority 100 ptype main action allow
sun:
ip xfrm policy add dst 192.168.0.1/32 proto tcp dport 5001 dir out priority 100 ptype main action allow
ip xfrm policy add dst 192.168.0.1/32 proto tcp dport 5001 dir fwd priority 100 ptype main action allow
ip xfrm policy add dst 192.168.0.2/32 proto tcp sport 5001 dir in priority 100 ptype main action allow
But, in this case, all tcp/5001 traffic from moon is *dropped* by xfrm (as
verified by nflog output).
I'd be happy to get manual bypass to work and use strongSwan for the default
encryption path. I'm perplexed as to why the above manual bypass doesn't work.
Any ideas?
Thank you in advance.
Plevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20160711/71645b1f/attachment-0001.html>
More information about the Users
mailing list