I have been trying to get OSPF running through a GIF tunnel with IPSEC with no success ... and I just find out why ... multicast packets are lost between the tunnel interface (gif0) and the physical interface (em0) I have setup the following: Client Router Server Public IP: em0: 3.3.3.2 ......... em1: 3.3.3.4 em0: 2.2.2.4 ......... em0: 2.2.2.3 Tunnel : gif0:172.17.10.2 <==========================> gif0: 172.17.10.1 Private IP: em1: 10.50.1.2 em1: 10.90.10.6 I have capture (using tcpdump) on the Client server, the packets going from the gif0 to the em0 interface and you can see that some of the OSPF hello packets are lost. I have capture files to prove it, and would like to provide them to you. The file that I can provide are named: Capture_1_FreeBSD82Client_gif0.cap Capture_1_FreeBSD82Client_em0.cap Looking at them with wireshark, it become apparent that packet are lost. Do not hesitate to contact me. JeanAumont@gmail.com Fix: I like to know how to fix it !!! How-To-Repeat: The problem is more easily reproduce when you put a Router between the Client and Server for some unknown reason.
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s).
Submitter: If this is still an issue with 10.2 RC2, please let us know so we can investigate.
(In reply to JeanAumont from comment #0) > I have been trying to get OSPF running through a GIF tunnel with IPSEC with > no success ... and I just find out why ... multicast packets are lost > between the > tunnel interface (gif0) and the physical interface (em0) FreeBSD doesn't forward multicast packets between interfaces. You need to configure it as multicast router. Did you done this?
Can you explain what is needed to configure it as multicast router? Is it simply some sysctl variables? I can not remember what was set-up since the ticket was open 4 years ago.
(In reply to JeanAumont from comment #4) Did you look at: https://www.freebsd.org/cgi/man.cgi?query=multicast&apropos=0&sektion=4&manpath=FreeBSD+10.2-RELEASE&arch=default&format=html
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Feedback timeout over 2 years. Also, this seem to work as intended: OSPF multicasts should not pass from the L3 tunnel interface to the LAN by default.