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

[Iris Su]

Hi  Graham,

Thanks for your kindly response.
It did solve our problem about broadcast packet processing.
BR,
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
> 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/20111205/9f39ea50/attachment.html>