Hi Graham, Thanks for your kindly response. It did solve our problem about broadcast packet processing. BR, Iris Su 2011/11/29 Graham Hudspith <[email protected]>
> 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 <[email protected]> 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. >> >> >>
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
