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

Iris Su iris.rj.su at gmail.com
Mon Dec 5 02:24:51 CET 2011

Hi  Graham,

Thanks for your kindly response.
It did solve our problem about broadcast packet processing.
Iris Su
2011/11/29 Graham Hudspith <graham.hudspith at gmail.com>

> 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
>, the ESP packet is sent to the real IP address (something like
>, but the IP destination address specified inside the
> encrypted ESP data is
> 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 dst tmpl src
> dst 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 dst
> This only worked when the remote end was provided with a netmask on tunnel
> setup. In this case, the netmask was
> 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.
>> Server may assign an IP (e.g. to client A and assign another
>> IP (e.g. to client B.
>> On Client A, it will have one outgoing xfrm policy -
>>     src dst dir out  ......
>>  On Client B, it will have one outgoing xfrm policy -
>>     src dst dir out  ......
>> Both client can send out broadcast traffic over tunnel without error
>> since the broadcast address ( is within the outgoing xfrm
>> policy.
>> On the other hand, the server side will have 2 outgoing xfrm policies -
>>     src dst dir out  ...... to Client A
>>     src dst 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 and
>>, 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
>> to client A and client B.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20111205/9f39ea50/attachment.html>

More information about the Users mailing list