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

Iris Su iris.rj.su at gmail.com
Thu Nov 24 09:52:00 CET 2011

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

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.

Best regards
Iris Su
2011/11/2 Martin Willi <martin at strongswan.org>

> Hi Graham,
> > Is it possible to send a packet to a subnet's broadcast address on the
> > secure side of a SeGW and have the packet sent down each IPsec tunnel
> > whose inner IP address belongs to that subnet ?
> It's not trivial, but it can be done. You'll need to:
>      * include the broadcast address into the IPsec tunnel
>      * separate the tunnels with the XFRM mark functionality to avoid
>        conflicts in the kernel
>      * open a socket that listens for broadcast packets and re-inject
>        them for each active tunnel using the XFRM mark of each tunnel
> I actually have some unreleased code that does exactly this. It does not
> perform that well because it handles broadcast sniffing and re-injection
> all in userspace, but it is usable. If performance is a problem, we'd
> have to delegate that job to the kernel.
> Another part of this plugin does the opposite, it listens for broadcasts
> coming from tunnels and re-injects them to the local subnet.
> The code is not usable out of the box, but let me know if you're
> interested. Maybe we'll find a solution how we could make it usable in a
> more generic way and include it in the mainline distribution.
> Best regards
> Martin
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20111124/2cd5b162/attachment.html>

More information about the Users mailing list