no neighbour

[smudge1977]

Running pimd on two pfsense machines with a layer 3 open vpn tunnel like this:

mc source -> pimd on pfsense ->openvpn layer 3 -> pimd on psense -> mc subscriber

Virtual Interface Table ====================================================== Vif Local Address Subnet Thresh Flags Neighbors

---

0 192.168.0.4 192.168 1 DR NO-NBR 1 10.99.1.1 10.99.1/24 1 DR NO-NBR

If I put in RP addresses of the other pfsense internal for a network of 239.99.0.0/16 for example I do see addresses from the other RP So my question is two fold...

If is specify RP for a range do I need a Neighbor?

The traffic between the two openvpn processes is going to be multicast traffic still so with OpenVPN on the pfsense boxes just block even though I have an any any rule with the extra IP options turned on on the OpenVPN layer 3 interface

[troglobit]

What version of pimd are you running? The latest official release is v2.3.2 and the master branch has a huge amount of fixes that are pending a very delayed release. You should definitely be able to run PIM across an L3 OpenVPN tunnel. Most of the times when peering fails, it's because the routers cannot hear each other, check the interface MULTICAST flag and ensure the PIM packets from each neighbor pass through the tunnel.

I do not believe it's enough to set a static RP for a range, because you'd still need to know that RP was PIM capable.

I do not understand the last question, but that's likely because I don't know much about pfSense. If it's the firewall you speak of then you need to allow PIM traffic on the tunnel interface, IP proto PIM (103).

[smudge1977]

So on digging deeper I think the issue is pimd will not bind to the openvpn interface at the remote site 10.98.1.1 (openvpn server) & 10.98.1.2 (openvpn client) The is tcpdump on the 10.98.1.2 remote site and we see the Hello

listening on ovpnc1, link-type NULL (BSD loopback), capture size 262144 bytes 11:03:15.755274 IP 10.98.1.1 > 224.0.0.13: PIMv2, Hello, length 26 11:03:15.755332 IP 10.98.1.1 > 224.0.0.1: igmp query v3 11:03:16.608393 IP 10.98.1.1 > 224.0.0.22: igmp v3 report, 3 group record(s)

But in pimd I see it ignores: 11:02:47.616 Ignoring group membership report from non-adjacent host 10.98.1.1

I assume because the interface is not in the interface table: `Virtual Interface Table ====================================================== Vif Local Address Subnet Thresh Flags Neighbors

---

0 192.168.224.128 192.168.224/20 1 DR NO-NBR 1 10.28.1.254 10.28/16 1 DR NO-NBR 2 10.27.1.254 10.27/16 1 DR NO-NBR 3 10.23.3.254 10.23.2/23 1 DR NO-NBR 4 10.24.1.254 10.24/16 1 DR NO-NBR 5 10.26.1.254 10.26/16 1 DR NO-NBR 6 192.168.0.1 192.168 1 DR NO-NBR 7 10.18.0.30 10.18.0.16/28 1 DR NO-NBR 8 10.42.98.254 10.42.98/23 1 DR NO-NBR 9 192.168.224.128 register_vif0 1

Vif SSM Group Sources I do not get the 10.98.1.2 interface in the Interface tabale Invalid phyint address 'ovpnc1' I have the interface in the config by name and IP: phyint vmx2.101 enable phyint 10.98.1.2 enable phyint ovpnc1 enable`

and this is ifconfig for that interface: ovpnc1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> inet6 fe80::20c:29ff:fe98:1ba6%ovpnc1 prefixlen 64 scopeid 0x12 inet 10.98.1.2 --> 10.98.1.1 netmask 0xffffffff nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> groups: tun openvpn Opened by PID 57519

I just add 10.98.1.1 in to the config (for the lols!) and still don't get a 10.98.1.x in the interfaces list Bit more log for your reference: `Config: phyint vmx2.101 enable phyint 10.98.1.2 enable phyint ovpnc1 enable phyint 10.98.1.1 enable

Log: 11:22:59.617 Getting vifs from kernel 11:22:59.617 Installing vmx0 (192.168.224.128 on subnet 192.168.224/20) as vif #0 - rate 0 11:22:59.617 Ignoring vmx0 (192.168.224.87 on subnet 192.168.224/20) (alias for vif#0?) 11:22:59.617 Installing vmx1 (10.28.1.254 on subnet 10.28/16) as vif #1 - rate 0 11:22:59.617 Installing vmx2.27 (10.27.1.254 on subnet 10.27/16) as vif #2 - rate 0 11:22:59.617 Installing vmx2.23 (10.23.3.254 on subnet 10.23.2/23) as vif #3 - rate 0 11:22:59.617 Installing vmx2.24 (10.24.1.254 on subnet 10.24/16) as vif #4 - rate 0 11:22:59.617 Installing vmx2.26 (10.26.1.254 on subnet 10.26/16) as vif #5 - rate 0 11:22:59.617 Installing vmx2.111 (192.168.0.1 on subnet 192.168) as vif #6 - rate 0 11:22:59.617 Installing vmx2.3 (10.18.0.30 on subnet 10.18.0.16/28) as vif #7 - rate 0 11:22:59.617 Installing vmx2.101 (10.42.98.254 on subnet 10.42.98/23) as vif #8 - rate 0 11:22:59.617 Getting vifs from /var/etc/pimd/pimd.conf 11:22:59.618 /var/etc/pimd/pimd.conf:8 - Invalid phyint address 'ovpnc1' 11:22:59.618 Local static RP: 169.254.0.1, group 232.0.0.0/8`

Oh and thanks for the great quick response obviously it is always great to see.

[troglobit]

What version of pimd are you running?

Older releases both disqualified interfaces/tunnels for various reasons and also did not find all interfaces on all systems due to using ioctls fot probe. If you're running v2.3.2 or older you likely have that limitation.

It's possible, but I have not tested, that setting up a GRE tunnel over the OpenVPN tunnel could be used as a workaround. This os obviously not ideal, the best solution is to have an up-to-date version that supports p-t-p links and can peer over OpenVPN directly.

[smudge1977]

Which file in the code FreeBSD gets the interfaces from the kernel? I will spin another pfSense and see at what point the gre interface stops been made available and raise a post in pfSense forum too

[troglobit]

What version of pimd are you running?

In pimd, the interface probing is (today) done in the file config.c ... not sure what you're asking for. I'm not that familiar with pfSense or FreeBSD, so it's quite hard for me to support them. I've done testing fairly recently, however, on FreeBSD running in Qemu, and there it works.

[smudge1977]

Great good to know I have simplified things and actually seem to be crashing the pfSense boxes! I get a neighbour and then as soon as MC traffic starts the destination pfSense firewall reboots

I now for testing have my home network 192.168.0.0/24 with two pfSense VMs (on ESXi) These have a WAN interface on the house network. There is a device on each internal LAN network of the pfSense firewalls for source / destination MC traffic Cause the WAN interface has NAT by default etc I created a link network between the two systems Enable PIMD on LAN & LINK and put in the Unicast routes to use the LINK between the two boxes.

I get a neighbour and then as soon as the traffic starts to flow the machine crashes.

I have just noticed I have built my pfSense boxes on Other 32bit in ESX and pfSense now uses FreeBSD 11 64Bit so I am rebuilding in ESX on the correct 'hardware' Be grate for this to work as obviously PIMD on the firewall makes a useful solution to getting MC traffic from site to site when required

[troglobit]

So we can close this issue then, not a problem with pimd right?

[smudge1977]

Going to close this one and open a new one I am sorry to say. I have now installed as per: https://troglobit.com/howto/pimd-on-freebsd/ FreeBSD 11 from FreeBSD website installed which is the pfSense OS

I have one interface with the receiver and one which is the link to the other pfSense. As soon as I run pimd with the default config the FreeBSD machine crashes.

Tell a lie - did it once but seems ok. Now just the other pimd reboots if i send multicast the other way and it is closest to the reciever.

Good - I will do some testing on the pfSense box compared to the clean FreeBSD box and share.

Thanks for all your quick responses

[smudge1977]

So the FreeBSD 11 machine does still core dump! I think close this issue and open a new one for 2.3.2 making FreeBSD 11 core dump.

Would you like the core dumps (page fault)? Given when you wrote the HowTo above I going to try pimd 2.1.8

[troglobit]

Sorry, but you're not the first to report kernel crashes with FreeBSD. Last time someone reported problems with pimd on non-Linux I spent the better part of a vacation week trying to figure it out, and it turned out do be a kernel bug. Such bugs are not the fault of pimd and should be reported to FreeBSD instead.

Due to the many problems that's been with FreeBSD (and also pfSense) in the past, As well as the lack of support from experienced developers that want to help out debug the upcoming v3.0 release. I've been forced to change the support status, as per the README: "Other UNIX variants (OpenBSD, NetBSD, FreeBSD, and Illumos) may also work, but are not officially supported.". I should perhaps ave mentioned this before, but at first this seemed to be a simple peering problem.

[smudge1977]

Totally get your issue and thanks for all your help. Time to bin it off I think as I can't compile 2.1.8 on FreeBSD - I hoped it was a library as when I installed git 66 other packages came down. this is the compile error - there is no ./configure in the 2.1.8 so I just ran make

config.c:751:5: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value] MASKLEN_TO_MASK(RP_DEFAULT_IPV4_HASHMASKLEN, my_bsr_hash_mask);

I do a bit of Python but not C - this is now out of my depth! Thanks and have a good weekend

[troglobit]

A lot has changed since 2.1.8, not just features but also bug fixes like the one you ran into. You could probably ignore the problem by editing the Makefile to remove -Werror, but I honestly don't remember what else you might need to do. That's close to 10 years ago.

Anyway, I'm closing this now.

[smudge1977]

I believe your GRE example will achieve what I want though to get Multicast traffic between the two sites and then I will want to just route the Multicast networks via R1 & R2 in your example so all the Unicast traffic does not flow though R1 & R2 and the GRE tunnel

[smudge1977]

Thanks again - much appreciated do you have a PayPal so I can send you a couple of beers or coffees??

[troglobit]

That's definitely possible. It should work with plain OpenVPN as well, but like I said in the beginning, that requires bleeding edge/unrreleased pimd from GIT.

Very kind of you, if you like you can use my email address in paypal; troglobit@gmail.com

Good luck! :)