Subject: [IPsec] IPSec processing in linux kernel acting as a gateway

From: "Prashant Batra (prbatra)" <[email-masked]>
Date: Thu, 17 Nov 2011 14:28:31 +0530

Hello,

One basic question related to IPSec processing on gateway.

I have established IPSec tunnels between two gateway (gw1 and gw2). On
gw1 I am using Linux kernel IPSec (a normal linux server which will act
as gateway).

The SPD and SAD database on gw1 is-

gw1#ip xfrm policy

src 172.16.80.1/32 dst 0.0.0.0/0

        dir fwd priority 1024

        tmpl    src 198.168.68.2 dst 192.168.101.101

                proto esp spi 0x00000000 reqid 0 mode tunnel

src 0.0.0.0/0 dst 172.16.80.1/32

        dir fwd priority 1024

        tmpl    src 192.168.101.101 dst 198.168.68.2

                proto esp spi 0x00000000 reqid 0 mode tunnel

src 172.16.80.1/32 dst 0.0.0.0/0

        dir out priority 1024

        tmpl    src 198.168.68.2 dst 192.168.101.101

                proto esp spi 0x00000000 reqid 0 mode tunnel

src 0.0.0.0/0 dst 172.16.80.1/32

        dir in priority 1024

        tmpl    src 192.168.101.101 dst 198.168.68.2

                proto esp spi 0x00000000 reqid 0 mode tunnel

gw1#ip xfrm state

src 198.168.68.2 dst 192.168.101.101

        proto esp spi 0x010000b8 reqid 0 mode tunnel

        replay-window 32

        auth hmac(sha1) 0x00c530455c9b7a4f3ed3824220a4c05e8b5edf97

        enc cbc(aes) 0x03d8c8ac752c2a9c4745f1a25a9f7da9

        sel src 172.16.80.1/32 dst 0.0.0.0/0

src 192.168.101.101 dst 198.168.68.2

        proto esp spi 0x00007aa1 reqid 0 mode tunnel

        replay-window 32

        auth hmac(sha1) 0x8d05b76456c9a52b51b6193f01c48a2fc27ada48

        enc cbc(aes) 0x75d062288ccb7355b0b8358f83323dd9

        sel src 0.0.0.0/0 dst 172.16.80.1/32

Now I am trying to send data from host1(behind gw1) 172.16.80.1 to host2
172.16.60.1 which is behind gw2.  But gw1 IPSec is not processing the
packets-

host1#ping 172.16.60.1 -I 172.16.80.1

gw1#tcpdump -I eth1

13:58:03.648171 IP 172.16.80.1 > 172.16.60.1: icmp 64: echo request seq
1 - plain icmp packets

13:58:04.647301 IP 172.16.80.1 > 172.16.60.1: icmp 64: echo request seq
2

13:58:05.647116 IP 172.16.80.1 > 172.16.60.1: icmp 64: echo request seq
3

Please correct me if I my understanding is wrong.

Thanks,

Prahsant

---

From: Paul Wouters <[email-masked]>
Date: Thu, 17 Nov 2011 12:18:43 -0500 (EST)

On Thu, 17 Nov 2011, Prashant Batra (prbatra) wrote:

> I have established IPSec tunnels between two gateway (gw1 and gw2). On gw1 I am using Linux kernel IPSec (a normal linux server which will act as gateway).

This might be off-topic for this list?

> gw1#ip xfrm policy

How did you create the policies? openswan? ipsec-tools? ip xfrm command?

> Now I am trying to send data from host1(behind gw1) 172.16.80.1 to host2 172.16.60.1 which is behind gw2.  But gw1 IPSec is not processing the packets-

You need to ensure your policy covers the subnets. In openswan terms that
is leftsubnet=172.16.80.0/24 and rightsubnet=172.16.80.0/24

> host1#ping 172.16.60.1 -I 172.16.80.1

Again, using openswan you can specify leftsourceip= and rightsourceip= to change
the default of using the "nearest IP to destination" (which is the public ip not
covered by the net-to-net IPsec policies) so your applications do not need to
do anything special (like -I in ping)

> Please correct me if I my understanding is wrong.

There are many things that can go wrong. Openswan provides the "ipsec verify" command
to test your system settings for forwarding, rp_filter, etc. Then you also need to ensure
you are not NATing packets, in your case:

iptables -I POSTROUTING -s 172.16.80.0/24 -d 172.16.60.0/24 -j RETURN

(and a mirrored rule on the other end)

If you are using the NETKEY stack, there is not much debugging you can
do, and tcpdump cannot show you outgoing encrypted packets (they are
encrypted after tcpdump can see them) so you should look on the other end
to see incoming ESP or UDP 4500 packets. If using the KLIPS ipsec stack,
you can tcpdump ipsec0 and eth0 seperately and see plaintext and crypted
packets normally.

If you are using openswan for your IKE daemon, please send any followups
to [email-masked] as this list is meant for IETF IPsec protocol
discussions.

Paul