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

_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Reply via email to