[strongSwan] Possible to broadcast packets down each IPsec tunnel from the SeGW ?

[Graham Hudspith]

Hi Iris,


The way I solved this in the end was to write my own program that created a
raw UDP socket. I wanted this socket to be able to send broadcast packets,
so I set the SO_BROADCAST option. I also wanted complete control over
specifying the IP header as well as the UDP contents, so I set the
IP_HDRINCL option.

I then composed my IP+UDP packet (as an array of unsigned char) and then
sent this down the raw socket to the inner IP address of the remote system.
This was running the program on the SeGW itself.

The IP header within my hand-built packet contents left the source IP
address as all-zeros (this was then populated by the Linux kernel on the
way out). The destination IP address was the subnet broadcast address. The
IP checksum was also all-zeros (and was also then populated by the Linux
kernel on the way out). I found it easier to also specify the UDP checksum
as all-zeros (i.e. "no" checksum).

Running wireshark, you can see an ESP packet going from the SeGW to the
remote end. Delving inside the ESP packet encrypted contents, you can see
that the IP destination address was still the broadcast address. So, using
the example numbers from below, I tell the raw socket to send the data to
10.17.0.1, the ESP packet is sent to the real IP address (something like
192.168.50.42), but the IP destination address specified inside the
encrypted ESP data is 10.17.0.255.

So, doing all of this, you can see the broadcast packet being delivered to
the remote end. However, we then found a problem in that the received
packet was being dropped and NOT being delivered to the application running
on the remote system.

We cured this by installing an extra xfrm policy on the remote end when the
IPsec tunnel is established. Something like:

ip xfrm policy add dir in src 0.0.0.0/0 dst 10.17.0.0/24 tmpl src 0.0.0.0
dst 10.17.0.255 proto esp mode tunnel

Of course, when the tunnel is taken down, the policy needs to be removed:

ip xfrm policy delete dir in src 0.0.0.0/0 dst 10.17.0.0/24

This only worked when the remote end was provided with a netmask on tunnel
setup. In this case, the netmask was 255.255.255.0.

This was all a bit of a hack, nothing as elegant as Martin's solution.
However, it got us out of a hole and allowed us to test the reception of
the broadcast packet. We'll leave it up to the SeGW vendor to actually
implement proper delivery of the broadcast packets to all attached clients !

Hope this helps (and makes sense),

Graham


On 24 November 2011 08:52, Iris Su <iris.rj.su at gmail.com> wrote:

> Hi  Martin,
>
> I'm interested in this topics (broadcast packets down each IPSec tunnel)
> as well. However, I still have some problem about this solution.
>
> Below is my understanding based on Graham's example.
>
>      our strongSwan-based SeGW defines a conn config entry in ipsec.conf
> where IPsec tunnels established using that config are assigned inner IP
> addresses from a pool (e.g. 10.17.0.0/24).
>
> Server may assign an IP (e.g. 10.17.0.1) to client A and assign another IP
> (e.g. 10.17.0.2) to client B.
>
> On Client A, it will have one outgoing xfrm policy -
>     src 10.17.0.1/32 dst 0.0.0.0/0 dir out  ......
>  On Client B, it will have one outgoing xfrm policy -
>     src 10.17.0.2/32 dst 0.0.0.0/0 dir out  ......
>
> Both client can send out broadcast traffic over tunnel without error
> since the broadcast address (10.17.0.255) is within the outgoing xfrm
> policy.
>
> On the other hand, the server side will have 2 outgoing xfrm policies -
>     src 0.0.0.0/0 dst 10.17.0.1/32 dir out  ...... to Client A
>     src 0.0.0.0/0 dst 10.17.0.2/32 dir out  ...... to Client B
> If we create a socket on server side which listen for broadcast
> packet, re-inject the packet to client A and client B, the packet will be
> transfered into a unicast one (with destination IP changed to 10.17.0.1 and
> 10.17.0.2, accordingly), is that correct?
>
> In that case, client A and client B still received a unicast packet, not
> broadcast one.
>
> Please tell me if my understanding correct or not, and let's discuss is it
> possible to send out broadcast packets (with dest address 10.17.0.254) to
> client A and client B.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20111129/e4928372/attachment.html>