[Openswan Users] [off-topic] was Re: [IPsec] IPSec processing in linux kernel acting as a gateway

[Prashant Batra (prbatra)]

Formatting-

-----Original Message-----
From: Prashant Batra (prbatra) 
Sent: Thursday, November 17, 2011 11:02 PM
To: 'Paul Wouters'
Cc: 'users at openswan.org'
Subject: RE: [off-topic] was Re: [IPsec] IPSec processing in linux kernel acting as a gateway

Hi Paul,

Thanks for directing me. I am not using open-swan, but it's a self-developed IKE deamon, wherein we are using kernel IPSec via NETLINK XFRM interface.
Including the openswan list, as it also uses kernel IPSec via same interface.
Please find my comments inline-

-----Original Message-----
From: Paul Wouters [mailto:paul at xelerance.com] 
Sent: Thursday, November 17, 2011 10:49 PM
To: Prashant Batra (prbatra)
Cc: ipsec at ietf.org
Subject: [off-topic] was Re: [IPsec] IPSec processing in linux kernel acting as a gateway

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

> 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-

This might be off-topic for this list?

> gw1#ip xfrm policy

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


<Prashant>Using IKE in-house developed IKE deamon.

> 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


<Prashant>Yes the policy added confirms the packet sent.
src 172.16.80.1/32 dst 0.0.0.0/0 - Any packet from src IP to any IP should be processed.

> 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)

<Prashant>not using openswan, so normal 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

<Prashant>-No NAT is present


(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.


<Prashant>I could only see the plain packets on the interface receiving the packets from host1, but no encrypted packets going out on other interface towards gw2.
Even noticed that the packet processed counters for IPSec SA are not getting increased, which means it's not hitting the IPSec layer probably.

If you are using openswan for your IKE daemon, please send any followups
to users at openswan.org as this list is meant for IETF IPsec protocol
discussions.

Paul