[strongSwan] IPCOMP question

[Jeremy Beker]

Martin,

Thank you for your test.  I have confirmed that the problem does not appear to be within StrongSwan.  Unfortunately the problem appears to be within the way the linux kernel (3.9.4 in my case) and iptables identify the compressed packets with regards to connection tracking.

I'll throw out the scenario I am seeing in case anyone has any ideas.

For obvious reasons, the workstation (client) that is initiating the ipsec tunnel with my server is firewalled up the ying-yang. The only packets I let in via iptables are those which are related to an outbound connection (using the ctstate module) or are inbound SSH over the VPN (which is unrelated to this problem).

Here are the relevant rules:

Chain INPUT (policy DROP 0 packets, 0 bytes)
target     prot opt in     out     source               destination
ACCEPT     all  --  any    any     anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     tcp  --  any    any     anywhere             anywhere             ctstate NEW tcp dpt:ssh policy match dir in pol ipsec

My setup is as follows:

Client A <--VPN--> Server <-- Private Network --> Client B

If I set up the tunnel without IPCOMP, I can ping from Cliuent A to Client B no problem with the rules above.  However, if I enable IPCOMP, the packets make it all the way from A to B and then back to A, but get blocked by iptables at client A.  It appears that the return ICMP packets are not getting associated with the outbound ICMP packets and therefore allowed back in.  (The same things happens with TCP, so it isn't limited to ICMP.)

I'll continue to play with it, but if anyone has any thoughts, I would appreciate it.

-Jeremy




On 06/03/2013 05:09 AM, Martin Willi wrote:
> Hi Jeremy,
>
>> I recently tried the patch which removes the restriction on IPComp from
>> NATd connections and unfortunately it appears not to work.
>
> I did some more testing with IPComp enabled over NAT.
>
> Everything seems to work fine here (on Linux 3.0.2), I can't reproduce
> the issue you are seeing. Works all as expected for different scenarios
> (virtual IP clients, forwarding gateway etc.).
>
>> 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
>
> It seems that some packets go through in both directions. To further
> debug this issue, I'd recommend to start a network sniffer on the
> involved hosts to see where exactly the packets get lost.
>
> Regards
> Martin
>
>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3883 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130604/5f7c2e4d/attachment.bin>