Many satellite ISP connections are indeed a problem for many VPN software drivers.

Without getting overly involved, the satellite interface s/w changes many things about the hierarchy of drivers on the machine that is actually connected to the satellite ISP "modem." The VPN software wants to monkey with the exact same bits of software. So right off the bat, there is likely to be an installation problem. One set of drivers will displace the other set of drivers, and nothing will work.

Now, I think (but I don't know for certain) that it might be possible to set up a PC on the satellite modem to act as a "router" or "gateway." Have this PC do as little as possible and don't install the VPN drivers on it, only the satellite drivers.

Then set up a second PC to do the "actual work" and set up the VPN drivers on this second machine. Route all traffic from the second computer to the first (by configuring your TCP/IP driver on the second machine to use the address of the first PC as the "default gateway" in your TCP/IP configuration window). What comes out the bottom of the second PC's VPN s/w looks and smells just like any other IP packet, so when routed to the gateway machine, these packets should be accepted and set out to the Internet just like any others. There might be a speed impact tho, and here's why:

The satellite drivers in the machine connected to the satellite "modems" are keeping close tabs on what is going on inside your IP traffic -- these satellite drivers are trying to "sniff" your TCP/IP packets and figure out ways to speed up the satellite ISP connection to minimize the impact of the up/down transmission delay. To do this, they need to insert some rather funky drivers in-between the TCP/IP driver in Windows and the Ethernet driver that detect what your asking for, the response to what you're asking for, and pre-fetch it, group it together, etc.

For example: you tell your web browser to bring up a web page. Let's say it is a weather page with lots of jpg's or jpeg's of the weather maps, etc.

You send out a request for the web page. You get a response - the response is html describing the web page, right?

What would happen on a DSL connection would be that your browser parses the HTML coming back at you and starts asking for the components in that web page -- all the embedded pictures, sounds, movies, etc. Your browser will often ask for perhaps only four things at a time.

The satellite s/w is "listening in" on your browsing session on both ends by digging into the payload portion of your TCP packets and parsing the HTML or XML stream. Your local s/w saw you ask for the page. Check. Now the other end of the satellite connection tells your local driver "I saw him ask for the page. Check."

Your local satellite s/w saw the page come back. Check. It is also then told by the remote end "Hey, I saw that there are 16 pictures on that page, I've already fetched them and here they come!"

Local software says "Gotcha" and starts to receive the embedded pictures for which your browser hasn't even generated a request yet.

Meanwhile, your browser generats a request for a bunch of these images on the page you browsed to. It parses the guts of that page and says "I'd like to get the first 4 images" and your local satellite s/w says "Got you covered -- me and my buddy on the other end of the satellite link already fetched them for you" and then hands up to the upper layer the pictures already fetched and transmitted by the other end. Your satellite driver completes the fetch of the pictures locally, without ever sending the request made by the browser for the pictures up to the satellite.

This is why when you go to download a file via satellite ISP's, you will see the following: You right click and choose "save as" on a file. While you're figuring out what to name the file, you see your satellite modem getting very busy. You enter a name and click "OK" -- and then you notice "Whoa! That first 400KB of the download was here pretty quick!" That's because it was already downloading before you hit "OK" -- the satellite s/w just started this without you.  

The TCP/IP drivers are usually at the top of the "networking driver stack" and talk to your applications (like your Internet Explorer, email program, etc). There can be other drivers on top of TCP/IP, eg, if you wanted to create another networking protocol on top of TCP, UDP or IP, you could layer another driver on top of TCP/IP.

The Ethernet driver will take IP packets and shovel them across the Ethernet wire to the modem; the Ethernet driver is pretty much the "bottom" of the "network driver stack" in most computer systems.

But what VPN is trying to do is intercept your TCP/IP packets, wrap your TCP/IP packets in another IP packet, and then hand off the packet to the Ethernet driver. On the other end, the system receiving your packet will pick up a TCP/IP packet, sniff down into the contents to see if it is a VPN packet, and if so, strip off the extra front portion (what networking people call an "encapsulation") and hand the newly exposed TCP/IP packet up to the TCP/IP stack. The innermost TCP/IP packets are using addresses, ports and sockets that exist only within your VPN. 

To do this, VPN wants to go into exactly the same location in the stack of drivers as the satellite sofware: in between your TCP/IP driver and your Ethernet driver. In theory, VPN could co-exist with the satellite s/w if there were a way to guarantee that the VPN s/w was layered on top of the satellite s/w, and the satellite s/w knew how to look inside a TCP/IP packet wrapped in a VPN packet to see how to speed up the satellite connection.

Sadly, Windows doesn't have a good way to say "I want to build a wedding cake, and I want this layer on top of that layer, and then these two layers on top of these other three layers over there..." and not all VPN implementations are the same, which makes things really difficult on the guys writing the satellite drivers.