VPN blocks multicast?

DaveDixon
DaveDixon used Ask the Experts™
on
I'm codeing a cross-platform client/server application that uses multicasting. I can test the application by running the client and the server on my XP laptop, as long as I'm not logged into my office network via VPN. Does MS VPN somehow snarf up the multicast packets?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Distinguished Expert 2017

Commented:
multicast relies on routing as well as the server side needs to receive the multicast registration packet.

See if the following articles get you closer to an answer/solution:
http://www.experts-exchange.com/Networking/Linux_Networking/Q_20596865.html
http://www.cisco.com/en/US/products/ps6604/products_white_paper09186a00800a3db6.shtml
http://www.velocityreviews.com/forums/t369263-multicasting-over-vpn.html

Author

Commented:
Thanks for the speedy reply. I've seen those links (the first one is what got me to experts-exchange in the first place). I may want to multicast over VPN someday, in which case they'll be very useful, but that's not my present problem.

Topology: Server and Client on the same computer (my laptop), at the same IP address, connected to an ISP through a Zoom DSL modem/router.

Typical usage: My Server sends out multicast packets on port 17000 to group 239.192.200.200.
Someone (I don't know who - my NIC, my router, my ISP) broadcasts it and my Client receives it. Everything is hunky dorey.

Problem: There's a VPN connection to another network (on a different domain and subnet). The VPN is irrelevant to the Client/Server - it just happens to be there. Multicast packets no longer come back to the Client. I'm assuming it's because they aren't going out (since my physical topology is unchanged) and that MS VPN is redirecting port 17000 or something.

It works the same way at work - if I run the server on my laptop and the client on a linux box, everything is cool. If I start up the VPN on my computer (which I have no reason to do, since I'm already on the internal network) the client no longer receives the packets.

That's the problem.
Distinguished Expert 2017
Commented:
I think the way it works is that the client has to register first by sending a multicast packet.  Once the multicast is received by the server that host is registered and will have multicast packets directed to it.

Compare the results of running netstat -rn from the laptop with and without the VPN.
What I am looking in particular is whether the establishment of the VPN has the effect of securing all networks.  This will be displayed through the VPN IP being used as the default gateway while the VPN is established.  This might be what the issue is.

Author

Commented:
That's it - VPN co-opted the default gateway as well as doubling up as the gateway for a number of network destinations (what that means I haven't a clue). It also explains why our jabber client doesn't work with VPN. Can I just take the default gateway back, or do I have to negotiate with our network admin? :)
Distinguished Expert 2017

Commented:
If you have a multi-network/site, it is simpler for the network/vpn admin to secure all networks and then manage access/routing internally. Versus trying to devise individual user/group policies to define which networks they can and cannot access (secure specific networks/sites).

You could try talking to the network admin, but it will likely be a waste of time.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial