openssh unix dev - Jan 2018 - TAP tunnels and multicast traffic

This setup is rather complex, so apologies for the length of this mail.
I'm also not at all sure where my problem is, so again I apologise if this
is the wrong place to ask.

I have a raspberry pi sitting in a remote office (hostname 'pi' below),
a
VPS hosted on someone's cloud (hostname 'vps' below) and my local
laptop
(hostname 'laptop').  The remote office then has another piece of
equipment
which is discoverable by sending a UDP multicast packet to a specific
multicast address and listening for a response.  I have a python script
that can discover this device and also some Windows software from the
vendor that can discover it.

What I'm trying to achieve is running the vendor's software locally and
have it discover the remote piece of equipment.

The raspberry pi connects to the VPS by SSH and opens a reverse channel,
connecting vps:127.0.0.1:9001 to pi:22.

I then ssh to the VPS and set up a local forward from laptop:9001 to
vps:9001.

I set up tap adapters on the laptop and the pi, both called tap0.  On the
pi, tap0 and eth0 are both connected to a bridge br0, which gets a LAN IP
address by DHCP.

I then connect to the pi from my laptop, using the two tunnels I've
described above, like this:

ssh -o Tunnel=ethernet -w 0:0 -p 9001 me at localhost
dhclient tap0
route del default

This works and tap0 gets an IP address on the remote LAN by DHCP (I haven't
figured out the DHCP magic to ignore the default route it's sent, so I have
to delete the new default route manually).  I can then run my python script
and discover the remote equipment - multicast UDP traffic is working across
the tunnel.

Now I kick off a VirtualBox VM running Windows 10.  It has a virtual
ethernet adapter which is bridged to tap0 on my laptop.  This comes up and
also receives an IP address on the remote LAN by DHCP and I can ping
addresses on the remote network.  At this stage, my python script running
on the laptop still works and can discover the remote equipment.

I then start the vendor's software and ask it to discover the remote
equipment.  This fails and, at the same time, my python script on the
laptop stops working.  I can still ping remote addresses from both the
laptop and the VM, but multicast UDP across the link no longer works.  Even
if I shut down the VM, the tunnel is still working for 'normal' IP
traffic
is still working but the multicast UDP discovery doesn't work any more.

Adding '-v' to the ssh commandline doesn't show anything happening
when I
run the vendor's software.

Before running the vendor's software, I can also run the python script on
the VM and it succeeds.  After I run the vendor's software, it fails.

If I exit ssh, kill dhclient, bring the local tap1 down and then start it
all back up again, it works again, until I run the vendor's software
again.  Then it fails again.

I don't even know where to start looking for the problem here.  Can anyone
give some advice or pointers in the right direction?

Thanks for reading,
Tom

On Tue, 30 Jan 2018, Tom Cook wrote:
> I then start the vendor's software and ask it to discover the remote
> equipment.  This fails and, at the same time, my python script on the
> laptop stops working.  I can still ping remote addresses from both the
> laptop and the VM, but multicast UDP across the link no longer works.  Even
> if I shut down the VM, the tunnel is still working for 'normal' IP
traffic
> is still working but the multicast UDP discovery doesn't work any more.
You could start by diffing the routing table on the Windows VM before
and after the vendor software runs, and/or running tcpdump or wireshark
to see what it's trying to do. Also consider running tcpdump on the
intermediate hops to see whether the multicast packets are propagating
as you'd expect.

-d

Also, what happens if you spin up the Windows VirtualBox VM, and then run the
Python script on the VM instead of the vendor software (assuming your Python
script is portable to Windows)?

-- 
jim knoble

> On Jan 30, 2018, at 17:30, Damien Miller <djm at mindrot.org> wrote:
> 
> 
> 
>> On Tue, 30 Jan 2018, Tom Cook wrote:
>> 
>> I then start the vendor's software and ask it to discover the
remote
>> equipment.  This fails and, at the same time, my python script on the
>> laptop stops working.  I can still ping remote addresses from both the
>> laptop and the VM, but multicast UDP across the link no longer works. 
Even
>> if I shut down the VM, the tunnel is still working for 'normal'
IP traffic
>> is still working but the multicast UDP discovery doesn't work any
more.
> 
> You could start by diffing the routing table on the Windows VM before
> and after the vendor software runs, and/or running tcpdump or wireshark
> to see what it's trying to do. Also consider running tcpdump on the
> intermediate hops to see whether the multicast packets are propagating
> as you'd expect.
> 
> -d
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev