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

[Iris Su]

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.

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>