VirtualPn

Category:Sasecurity
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!?
=== VPN intermesh tunnels ===