Hi Iris,<blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>We cured this by installing an extra xfrm policy on the remote end when the IPsec tunnel is established. Something like:</div><div><br></div><div>ip xfrm policy add dir in src <a href="http://0.0.0.0/0">0.0.0.0/0</a> dst <a href="http://10.17.0.0/24">10.17.0.0/24</a> tmpl src 0.0.0.0 dst 10.17.0.255 proto esp mode tunnel</div>
<div><br></div><div>Of course, when the tunnel is taken down, the policy needs to be removed:</div><div><br></div><div><div>ip xfrm policy delete dir in src <a href="http://0.0.0.0/0">0.0.0.0/0</a> dst <a href="http://10.17.0.0/24">10.17.0.0/24</a></div>
</div><div><br></div><div>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.</div><div><br></div><div>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 !</div>
<div><br></div><div>Hope this helps (and makes sense),</div><div><br></div></blockquote><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div>Graham</div></blockquote></blockquote><div><br><div class="gmail_quote">On 24 November 2011 08:52, Iris Su <span dir="ltr"><<a href="mailto:iris.rj.su@gmail.com">iris.rj.su@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>Hi Martin,</div>
<div> </div>
<div>I'm interested in this topics (broadcast packets down each IPSec tunnel) as well. However, I still have some problem about this solution. </div>
<div> </div>
<div>Below is my understanding based on Graham's example.</div><div class="im">
<div> </div>
<div> 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. <a href="http://10.17.0.0/24" target="_blank">10.17.0.0/24</a>).</div>
<div> </div>
</div><div>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. </div>
<div> </div>
<div>On Client A, it will have one outgoing xfrm policy - </div>
<div> src <a href="http://10.17.0.1/32" target="_blank">10.17.0.1/32</a> dst <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> dir out ......</div>
<div>
<div>On Client B, it will have one outgoing xfrm policy - </div>
<div> src <a href="http://10.17.0.2/32" target="_blank">10.17.0.2/32</a> dst <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> dir out ......</div></div>
<div> </div>
<div>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.</div>
<div> </div>
<div>On the other hand, the server side will have 2 outgoing xfrm policies -</div>
<div> src <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> dst <a href="http://10.17.0.1/32" target="_blank">10.17.0.1/32</a> dir out ...... to Client A</div>
<div> src <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> dst <a href="http://10.17.0.2/32" target="_blank">10.17.0.2/32</a> dir out ...... to Client B<br></div>
<div>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? </div>
<div> </div>
<div>In that case, client A and client B still received a unicast packet, not broadcast one. </div>
<div> </div>
<div>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.</div>
<div> </div>
<div><br></div></blockquote></div></div>