DaveDixon
asked on
VPN blocks multicast?
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?
ASKER
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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? :)
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.
You could try talking to the network admin, but it will likely be a waste of time.
See if the following articles get you closer to an answer/solution:
https://www.experts-exchange.com/questions/20596865/Multicast-routing-over-a-VPN.html
http://www.cisco.com/en/US/products/ps6604/products_white_paper09186a00800a3db6.shtml
http://www.velocityreviews.com/forums/t369263-multicasting-over-vpn.html