General Computing
linux networking ip compression
Updated Tue, 09 Aug 2022 14:59:59 GMT

IP payload compression with xfrm


I'm trying to compress IP payload with ip xfrm between 2 computers. Computer 1 has the IP address 192.168.0.1 and computer 2 has 192.168.0.2. I successfully established a IPSec link between the 2 machines following this gist. I tried to adapt it for the compression. I ran the following command :

Computer 1

sudo ip xfrm state add src 192.168.0.1 dst 192.168.0.2 proto comp comp deflate
sudo ip xfrm policy add src 192.168.0.1 dst 192.168.0.2 dir out tmpl proto comp

Computer 2

sudo ip xfrm state add src 192.168.0.1 dst 192.168.0.2 proto comp comp deflate
sudo ip xfrm policy add src 192.168.0.1 dst 192.168.0.2 dir in tmpl proto comp

I first test it by pinging C2 with C1 and I'm capturing the traffic between with Wireshark. The PING is working in only 1 way : just the request is sent (no respond found displayed on C2 and no reply sent) and on Wireshark I'm not seeing any compression in any direction. I interpreted that as the payload is too small so xfrm doesn't compress the packet.
Then I tried to established a SSH connection from C1 to C2. SSH is working fine without compression enabled. When I enable the compression, Wireshark shows compressed packets, but the SSH client is waiting endlessly (same reason as PING) and end up with a connection timed out. I think this is because M2 doesn't decompress the IP packages, packages can't be read and are dropped.

I know that those rules are not bidirectional and are only for an "upload" direction. So I also tried by completing with the rules for download : switching IPs and dir policy. It's end up with the same results.

My questions are : Where am I wrong ? Which is the good way to use xfrm to have compression and get working the 'download' link ?

Ps : I'm quite new and the lack of explanation made xfrm quite difficult to understand how to properly use it and how it's working. So my interpretation earlier my be wrong.

Solution

This line is improper:

PC2

sudo ip xfrm policy add src 192.168.0.1 dst 192.168.0.2 dir in tmpl proto comp

It causes PC2 blocking packets from PC1 that are not compressed (due to small packet size).

In the following configs, ping -s1000 192.168.0.2 from PC1 may succeed, while ping -s56 192.168.0.2 gets no response:

PC1

sudo ip xfrm policy add src 192.168.0.1 dst 192.168.0.2 dir out tmpl proto comp mode transport
sudo ip xfrm state add src 192.168.0.1 dst 192.168.0.2 proto comp spi 2 comp deflate mode transport
sudo ip xfrm policy add src 192.168.0.2 dst 192.168.0.1 dir in tmpl proto comp mode transport
sudo ip xfrm state add src 192.168.0.2 dst 192.168.0.1 proto comp spi 2 comp deflate mode transport

PC2

sudo ip xfrm policy add src 192.168.0.1 dst 192.168.0.2 dir in tmpl proto comp mode transport
sudo ip xfrm state add src 192.168.0.1 dst 192.168.0.2 proto comp spi 2 comp deflate mode transport
sudo ip xfrm policy add src 192.168.0.2 dst 192.168.0.1 dir out tmpl proto comp mode transport
sudo ip xfrm state add src 192.168.0.2 dst 192.168.0.1 proto comp spi 2 comp deflate mode transport

By removing those lines that contain "xfrm policy add .* dir in tmpl proto comp", ping -s56 192.168.0.2 from PC1 succeeds, as well as other connections such as SSH. As a result:

PC1

sudo ip xfrm policy add src 192.168.0.1 dst 192.168.0.2 dir out tmpl proto comp mode transport
sudo ip xfrm state add src 192.168.0.1 dst 192.168.0.2 proto comp spi 2 comp deflate mode transport
sudo ip xfrm state add src 192.168.0.2 dst 192.168.0.1 proto comp spi 2 comp deflate mode transport

PC2

sudo ip xfrm state add src 192.168.0.1 dst 192.168.0.2 proto comp spi 2 comp deflate mode transport
sudo ip xfrm policy add src 192.168.0.2 dst 192.168.0.1 dir out tmpl proto comp mode transport
sudo ip xfrm state add src 192.168.0.2 dst 192.168.0.1 proto comp spi 2 comp deflate mode transport





External Links

External links referenced by this document:

References