peer-peer vpn solutions?

How can you do site-to-site, if the remote site is roaming?

Get a router that does IPSec tunnels, the Linksys BEFVP41 and the BEFSX41 does site-to-site VPN, even with dynamic addresses on one end. Of you do the VPN Router method you can get a cheap access point and sell your WRV54G on ebay to recoup some of the cost.

Site-to-site VPN (IPSec tunnesl) are the best way to go - you can specify what addresses are exposed on each side of the VPN using the Linksys routers.

You only need one end to be fixed, the remote has to know the IP of the local office. A simple user name / password starts the handshake.

Which firmware were/are you using with the SX41? It has a troublesome history of firmware!

In article , Leythos wrote: :Get a router that does IPSec tunnels, the Linksys BEFVP41 and the BEFSX41 :does site-to-site VPN, even with dynamic addresses on one end.

Data points:

I recently started testing both BEFVP41 and BEFSX41. The BEFSX41 user interface has more layers and makes it harder to find important settings than the BEFVP41; the BEFSX41 also has the option to view the IPSec negotiation log greyed out, so it's not a good choice until the connection is already debugged.

The BEFSX41 is aggressive about making the IPSec connections -- it connects as soon as you save the settings, and it automatically reconnects if power is lost. And under the PPPoE setting, there is a timeout available, implying that it will do "demand connections" upon seeing traffic. This is good for unattended lan-to-lan use.

The BEFVP41 has explicit 'Connect' buttons; I haven't tested it enough yet to see if it will automatically reconnect; I think I observed that it did not in some cases, but that night was a pretty late night and I should retest with possibilities such as telling it to save the settings -while- the link is connected.

With the BEFSX41, I observed a few times that my active TCP connection (i.e., one I was typing into at the time) would hang and not come back, but existing connections in my other windows were entirely unaffected. I had a look at my PIX logs and notice that at the time of the freeze, the relevant Security Associations were deleted; I haven't checked into this in detail. It is something that I -never- observed in a few years of using a PIX in the same position. And I can't think of any good reason why an individual TCP connection would be affected.

With the BEFVP41 I have not observed the same freezing behaviour, but I have not tested the BEFVP41 for the same length of time.

Whether the BEFSX41 freeze is a minor annoyance or something unacceptable would depend on individual preference and on the application.

Both the BEFVP41 and BEFSX41 had no difficulties in connecting to a remote PIX configured with an appropriate "isakmp key" and "crypto dynamic map" -- i.e., a standard fully-specified pre-shared-key IPSec connection. I have not made any attempt to connect to a PIX set up to expect Cisco's EzVPN negotiations, and I did not happen to look at the connection logs to see whether either device would be recognized by the PIX as a "Unity client".

The only time you see the delay, and it's in the SX and VP units, is when one side does not have a fixed IP on the net.

Both the SX and VP units will auto-reconnect after a power outage or if your internet connection goes down/reconnects.

You can change the tunnel duration from 1 hour to 24 hours, and I do this for some installations, which limits the lag of rebuilding the tunnel on a dynamic link to once per day.

In article , Leythos wrote: :On Sat, 16 Apr 2005 18:25:02 +0000, Walter Roberson wrote: :> Whether the BEFSX41 freeze is a minor annoyance or something :> unacceptable would depend on individual preference and on the :> application.

:The only time you see the delay, and it's in the SX and VP units, is when :one side does not have a fixed IP on the net.

Thanks for the information. Could you expand on whether that is true if the units have outside DHCP (or PPPoE) turned on, or only when the outside IP actually changes? My DSL PPPoE lease time is roughly one week and the incidents I saw occured once or twice a day.

:You can change the tunnel duration from 1 hour to 24 hours, and I do this :for some installations, which limits the lag of rebuilding the tunnel on a :dynamic link to once per day.

Perhaps I should have phrased my point another way.

I'm accustomed to tunnel rebuilds (e.g., with the PIX) and -pauses- for rebuild would not be a concern. The difficulty I encountered with the SX was that the TCP connection itself would die, irrecoverably. In each case it was a TCP connection I was actively typing data into, and suddenly no more data would go through it and my local side would retry and eventually after several minutes decide it wasn't coming back. Meanwhile, the other TCP connections I had open to the same host, which I hadn't been busy typing into, were completely fine and didn't notice the tunnel teardown and rebuild at all.

I've been using a PIX 501 in the configuration for years, and this never happened with it -- with the PIX, any circumstance that delayed or destroyed connections would affect all the connections equally.

You're talking two different things:

1) The connection to the internet can be fixed or dynamic - PPOE is not as nice as a cable modem (normal ethernet/dchp connection), but it does work.

2) In the case of a WAN connection on a Dynamic IP, you can't specify the IP of this connection from the other end - so that means that the one with a Dynamic IP has to contact the one with a fixed IP, which also means that the one with the Dynamic IP will timeout when there is no tunnel traffic, and it will not renew the tunnel until traffic starts again.

Update the firmware to the latest version, I've not seen this anywhere. We've got about 30 VP units and 12+ SX units in customers homes. None of them are on DSL, all are on high speed cable.

What are you connecting the SX/VP to on the other end?