[strongSwan] IPCOMP question

Tue May 21 18:02:09 CEST 2013

All,

I recently tried the patch which removes the restriction on IPComp from NATd connections and unfortunately it appears not to work.  The VPN connection comes up successfully and looks fine via ipsec statusall (and shows compression), but I am not able to successfully pass data across the connection.

I am running 5.0.4 with only that patch applied.  The only difference between a working setup and one where no packets make it through is 'compress=yes" vs. "compress=no."  Both ends of the tunnel are Linux boxes (Fedora 17&18) but I have compiled Strongswan 5.0.4 from source on my own.

I'm happy to share more information or test to help.

-Jeremy

Here is the client statusall from the working link (I've blanked out IP addresses):

Status of IKE charon daemon (strongSwan 5.0.4, Linux 3.8.11-200.fc18.x86_64, x86_64):
   uptime: 46 minutes, since May 21 11:09:50 2013
   malloc: sbrk 2568192, mmap 0, used 321056, free 2247136
   worker threads: 8 of 16 idle, 7/1/0/0 working, job queue: 0/0/0/0, scheduled: 16
   loaded plugins: charon aes des sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs8 pgp dnskey pem openssl fips-prf gmp xcbc cmac hmac attr kernel-netlink resolve socket-default stroke updown xauth-generic
Listening IP addresses:
   <server IP>
Connections:
         home:  %any...<server hostname>  IKEv2, dpddelay=30s
         home:   local:  [User Certificate] uses public key authentication
         home:    cert:  "User Certificate"
         home:   remote: [Server Certficate] uses public key authentication
         home:   child:  0.0.0.0/0 ::/0 === 0.0.0.0/0 ::/0 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
         home[7]: ESTABLISHED 32 minutes ago, <server IP>[User Certificate]...<client IP>[Server Certficate]
         home[7]: IKEv2 SPIs: 167fdb51a6870c81_i* 2831216ecec970a1_r, public key reauthentication in 22 minutes
         home[7]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
         home{7}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c9c99f2b_i c343354a_o
         home{7}:  AES_CBC_128/HMAC_SHA1_96, 1083043 bytes_i (969 pkts, 1s ago), 69478 bytes_o (720 pkts, 1s ago), rekeying in 12 minutes
         home{7}:   192.168.3.0/24 2001:470:e465:2::/64 === 0.0.0.0/0 ::/0

Here it is with 'compress=yes' where it doesn't work:

Status of IKE charon daemon (strongSwan 5.0.4, Linux 3.8.11-200.fc18.x86_64, x86_64):
   uptime: 47 minutes, since May 21 11:09:49 2013
   malloc: sbrk 2568192, mmap 0, used 322160, free 2246032
   worker threads: 8 of 16 idle, 7/1/0/0 working, job queue: 0/0/0/0, scheduled: 19
   loaded plugins: charon aes des sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs8 pgp dnskey pem openssl fips-prf gmp xcbc cmac hmac attr kernel-netlink resolve socket-default stroke updown xauth-generic
Listening IP addresses:
   <server IP>
Connections:
         home:  %any...<server hostname>  IKEv2, dpddelay=30s
         home:   local:  [User Certificate] uses public key authentication
         home:    cert:  "User Certificate"
         home:   remote: [Server Certficate] uses public key authentication
         home:   child:  0.0.0.0/0 ::/0 === 0.0.0.0/0 ::/0 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
         home[8]: ESTABLISHED 8 seconds ago, <server IP>[User Certificate]...<client IP>[Server Certficate]
         home[8]: IKEv2 SPIs: 13d7c3e50e8749c3_i* 5aae569016a80b77_r, public key reauthentication in 56 minutes
         home[8]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
         home{8}:  INSTALLED, TUNNEL, ESP in UDP SPIs: cd94aad3_i c7eb5299_o, IPCOMP CPIs: 3193_i d361_o
         home{8}:  AES_CBC_128/HMAC_SHA1_96, 10999 bytes_i (43 pkts, 5s ago), 1603 bytes_o (25 pkts, 0s ago), rekeying in 16 minutes
         home{8}:   192.168.3.0/24 2001:470:e465:2::/64 === 0.0.0.0/0 ::/0

> Hi Martin.
>
> I can not wait for next release and I have compiled strongswan with patch you had offered.
> Now IPCOMP works through NAT.
>
> Many thanks.
>
>
> В Fri, 17 May 2013 08:49:53 +0700
> Anton <warm at mtele.pro> пишет:
>
>> Hi Martin.
>>
>> Thanks. I'll try with next release of strongswan.
>>
>>
>> On Thu, 16 May 2013 13:43:39 +0200
>> Martin Willi <martin at strongswan.org> wrote:
>>
>> > Hi Anton,
>> >
>> > > So why IPCOMP does not work through NAT or UDP encapsulation ? I
>> > > suspect there is some fundamental reason (protocols restrictions or
>> > > so).
>> >
>> > There is no protocol restriction or something that could prevent IPComp
>> > for working over NAT. However, there were some restrictions with the way
>> > charon installed the compression SA bundle.
>> >
>> > It seems that these restrictions don't apply anymore with the way we
>> > handle those SA bundles now. In my testing it seems that compression
>> > works fine both over connections with forceencaps and over NAT. You may
>> > try the patch at [1] that allows you to use compression on such
>> > connections, let me know if that works for you.
>> >
>> > Regards
>> > Martin
>> >
>> > [1]http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=refs/heads/ipcomp-nat
>> >
>> >
>>
>>

-- 
Jeremy Beker - gothmog at confusticate.com
http://www.confusticate.com
Condensing fact from the vapor of nuance.