VirtualPn

back to http://scratchpad.wikia.com/wiki/Sasecurity

Subnet conflicts
* SubnetConflicts * VpnMac * MultipleNat * ProVersionvpn * VpnTonode

sssss
VPN disconnects

OSS - Opensource version of http://www.locustworld.com mesh. PRO is the pay for version 1. You can put an OSS or a PRO box on a public IP anywhere on the internet and VPN to it coming in on the eth0 interface. 2. I've used OSS mesh boxes to join two or more Windows computers together, each one can VPN to the mesh box, they are all on the same SubNet, so they can all communicate as if they were on the same LAN, despite the fact that the windows PCs are behind any manner of cheap routers and dodgy NAT systems, and geographically dispersed. 3. Additionally, VPN clients of an OSS mesh box can also see the wireless clients attached to that mesh box as well. 4. In Pro, the individual VPNs are firewalled from each each other and from the wireless clients, so you cannot use the mesh box as a VPN hub, although you can use it in the same manner as Kenny described. Having a spare mesh box with OSS on it, via a public IP can solve all sorts of customer issues such as allowing strange VPN's, curing network games that do not work because of P2P blocking, and of course if you are a customer of your own mesh, being able to use bittorrrent to bring down the latest Linux distributions. This is not so much of an necessity now that the P2P blocking on Pro is a little more relaxed than it was a couple of years ago, where it blocked all UDP traffic.

I took suggestion about a VPN connection and I decided to do some quick experimenting and the VPN connection worked fine between my   laptop here at home (1 hop out into the mesh) and our gateway meshbox (Pro 2137). Therefore I created an account for her and emailed her the instructions on how to set it up on her computer. Like I said, she is 2 hops out. She followed my instructions and now is reporting that she is   now able to connect to her corporate VPN. Yay!

Therefore, this workaround holds up for clients using the 10.x.x.x   scheme as well in some cases.

One thing I want to question, I have her connecting to our gateway meshbox (Pro2137) instead of a standalone OSS meshbox. Why was the OSS solution mentioned - is there a reason that one would want to use an   OSS box as suggested?

ad
First of all, this client lives in Texas but is connected to our Louisiana network (about 8 miles and 2 hops from the gateway). The option of setting up a box off the mesh for her to connect to is not feasible.

I took Joe's suggestion about a VPN connection and I decided to do some quick experimenting and the VPN connection worked fine between my laptop here at home (1 hop out into the mesh) and our gateway meshbox (Pro 2137). Therefore I created an account for her and emailed her the instructions on how to set it up on her computer. Like I said, she is 2 hops out. She followed my instructions and now is reporting that she is now able to connect to her corporate VPN. Yay!

Therefore, this workaround holds up for clients using the 10.x.x.x scheme as well in some cases.

One thing I want to question, I have her connecting to our gateway meshbox (Pro2137) instead of a standalone OSS meshbox. Why was the OSS solution mentioned - is there a reason that one would want to use an OSS box as suggested?

asdf
This solution has worked for some VPN systems.

Setup an OSS mesh box (not pro) on a public ip. Get the customer to make a standard windows pptp vpn to your mesh box, then try to connect using vpn client software.

I think that is going to be the case with her. I'm not sure what vendor she is using, though. Since the mesh uses 10.x.x.x and 172.x.x.x, then we're dealing with the same issue that you guys have.

> what VPN software is she using? > > At work we use CheckPoint SecureRemote, and if the host IP uses either > 10.x.x.x or 172.x.x.x address ranges then our users cannot make a > usable > connection to our intranet due to the fact that we use those two > address > ranges as well. > > If she is using CheckPoint then there isn't a whole lot you can do... > unless you want to change your LAN/WAN to not use those address > ranges...

asdfasf
I think that is going to be the case with her. I'm not sure what vendor she is using, though. Since the mesh uses 10.x.x.x and 172.x.x.x, then we're dealing with the same issue that you guys have. > what VPN software is she using? > > At work we use CheckPoint SecureRemote, and if the host IP uses either > 10.x.x.x or 172.x.x.x address ranges then our users cannot make a > usable > connection to our intranet due to the fact that we use those two > address > ranges as well. > > If she is using CheckPoint then there isn't a whole lot you can do... > unless you want to change your LAN/WAN to not use those address > ranges...

>> I have a client that is trying to use a VPN and keeps getting abruptly >> disconnected. TcpDump is showing her trying to connect to a 10.0.x.x >> address. I wonder if there could be a conflict with the internal mesh >> ip scheme? Has anyone ever seen this? If so - how can it be fixed or >> worked around!?

tgere
what VPN software is she using?

At work we use CheckPoint SecureRemote, and if the host IP uses either 10.x.x.x or 172.x.x.x address ranges then our users cannot make a usable connection to our intranet due to the fact that we use those two address ranges as well. If she is using CheckPoint then there isn't a whole lot you can do... unless you want to change your LAN/WAN to not use those address ranges...

> I have a client that is trying to use a VPN and keeps getting abruptly > disconnected. tcpdump is showing her trying to connect to a 10.0.x.x > address. I wonder if there could be a conflict with the internal mesh > ip scheme? Has anyone ever seen this? If so - how can it be fixed or > worked around!?