# Multi-Room Viewing/VPN Help



## hugetivofan (Feb 24, 2001)

Trying to network two tivos in two different houses (same account). It sounds like it has been tried before without reports of success. Lots of suggestions to use a slingbox, but id like to do it with tivos. I would like to be able to transfer shows between tivos using multi room viewing, over a vpn connection. Have FIOS on one end so 35Mbps upstream should make it workable at least in one direction. Here is my setup:

Home 1: Series 3 tivo, cable modem, VPN box local ip 192.168.1.11
Home 2: Tivo Premiere, fios, VPN box local ip 192.168.1.10

at each end, i have installed a netgear vpn system (fvs338). Home 1 VPN system is plugged into a cable modem (not router) and issues IPs via DHCP in the range of ...12 to ...19. Home 2 VPN system is plugged into FIOS modem/router and issues IPs via DHCP in the range of ...20+. FIOS router is redirected to VPN system in manner described in this link (scroll down to see post w/ list 1-8):

http://arstechnica.com/civis/viewtopic.php?f=10&t=35814&hilit=FIOS+VPN

Both VPN systems set up with dynamic DNS services. They can see each other and set up a connection (right now it says "IPSec SA established"). But I cant ping the Home 2 VPN box from a Home 1 computer. I thought I was successful at pinging a Home 1 device (not sure which) from a Home 2 computer, but I can't be sure as I've been constantly changing settings to try to get this to work.

Also tried setting local IPs on both VPN boxes to the same address (suggested in another post), that didnt work either.

Any ideas out there? I am familiar w networking stuff but have never done a VPN before. One q I have is is there any way for me to manage both ends at the same time? I set up Home 2 this weekend and now I am at Home 1 and frustrated that I can't do anything with the Home 2 setup.

But more importantly, how can I get this to work?

Thanks in advance for any help!


----------



## Ckought (Nov 29, 2006)

TiVos can only see other TiVos within the same subnet.

Although you have routers at both ends spitting out DHCP numbers within the same Class-C range, they are still two distinct subnets (otherwise, the routers wouldn't know what packets to route within its own network and what packets to pass to the other network).

There shouldn't be a problem communicating from a computer in Home 1 to a computer in Home 2 because computers are designed to communicate outside their own subnet -- but TiVo has seen fit to code their software to ignore any external traffic.

In the past, the reasons I've seen given for the limitation have regarded fees and distribution licensing. TiVo would rather charge the full-rate for each house than to charge one full-rate and the other (in the 2nd house) the multi-room discount rate. And I think, in the past, there was pressure from networks (HBO, Showtime, etc) worried about households grouping together and paying for the service at one house and then sharing the shows with the other households (that's also why TiVo uses the MAK, so pay channels can't be recorded on one person's TiVo and played back to other people's TiVos).


----------



## hugetivofan (Feb 24, 2001)

Thanks for the quick reply. Re subnets I have both VPN boxes set to the same subnet (255.255.255.0) - are you saying that even so, they are still separate and distinct subnets? Is there no way to create a VPN that has a single subnet at both locations?


----------



## orangeboy (Apr 19, 2004)

hugetivofan said:


> Thanks for the quick reply. Re subnets I have both VPN boxes set to the same subnet (255.255.255.0) - are you saying that even so, they are still separate and distinct subnets? Is there no way to create a VPN that has a single subnet at both locations?


I had trouble wrapping my mind around that explanation of separate/distinct subnets. My thought was the point of a VPN was to securely extend a private LAN to a remote location, where hosts would logically appear to be on the same network. But when NATing gets involved (which it must because of the FiOS/Cable modem networks the packets must traverse), I have to claim ignorance.

Question though: How does dynamic DNS play a role in this? Is it only for easily identifying the VPN devices?


----------



## Ckought (Nov 29, 2006)

hugetivofan, if you have your subnet masks set to 255.255.255.0 on your routers, then they won't be able to distinguish whether to keep a packet internally or send it externally. You can have several subnets within the same Class C range, but each subnet needs to have the correct subnet mask defining the subnets so routers can know what do do with the packets.

orangeboy, the point of a VPN is to connect two network segments so that they can communicate securely. You can have more than one subnet within a network, and they all will communicate with each as if they're physically on the same network -- but each segment still needs to have its own subnet for routing purposes.

Where I work, we have over 80 locations spread out over a large geographical area and each location has its own subnet (some larger locations having more than one subnet). If my computer sends a packet to a computer several hundred miles away, the packet leaves my computer and makes its way to the router on my side; my router sees that it's not an internal subnet and passes it off to the VPN tunnel for the remote location; at the remote location, the packet is comes out of the VPN tunnel, and the router determines if the packet belongs to that subnet; if it does, then the packet goes through that network to the destination computer.

It may make it easier to understand what's happening if you break up the two concepts of routing and VPN. VPN is just encrypting the data between two points; routing is the process of getting packets from point-A to point-B and does it the same way whether or not the packets are encrypted.


----------



## hugetivofan (Feb 24, 2001)

orangeboy, I am using dynamic DNS because I don't have static IPs at either location. So the dynamic DNS should allow me to keep up the connection even when my ISP changes my IP at either location.

Ckought, thanks for your detailed replies. I will try to change the subnets tonight - maybe that is why I havent been able to ping across networks. It seems that you know VPNs well, so I hope you don't mind if I keep asking a few questions:

1) Doing some googling on the topic, it seems that some refer to what you have called the "Class-C" range as the "subnet" and what I have been calling the "subnet" as the "subnet mask". We are talking about the duplicate 255.255.255.0 here, correct?
2) Why would the VPN establish a secure connection but then not be able to send traffic back and forth? It sounds like from your VPN vs router separation comment it must be a routing problem then (presumably the subnet?)
3) If it is purely a routing problem then would something like what is suggested below work to resolve the subnet issue?

http://www.dd-wrt.com/phpBB2/viewtopic.php?t=4786

4) I have used the vanilla "VPN Wizard" to establish the connection between the two boxes, but I can configure it manually as well. Any suggestions on other changes I might want to try to the VPN configuration?

Thanks again!


----------



## Stormspace (Apr 13, 2004)

I gave this a little thought and think I have a workaround for you. If the TiVo's at both places use the same MAK, you could off load the shows that you want to be in both places to a network drive that can be mapped from the other house. Then you'd use that network location at the other house as your TiVo Desktop folder. If you needed to pull down a show that wasn't in the list, you could use a logmein or VNC client to connect to the TiVo Desktop machine at the other house to schedule it.

If you had network space to spare, you could run a scheduled task to keep the shows at both houses synchronized.


----------



## Ckought (Nov 29, 2006)

hugetivofan, I don't mind answering any of your questions that I can.

"Class-C" and "255.255.255.0" both pretty much have the same meaning. Class-C is a subset (subnet) of 256 IP addresses from the entire available IPV4 range. When you are using a subnet of 192.168.1.XXX (where the XXX is the IP range of 0-255), then it would have a "subnet mask" of 255.255.255.0 (which tells the router that the first three numbers within that network are all the same, and the last number has 256 IPs). There are subnets that are smaller than Class-C (256 IPs) -- you can create a subnet with as few as 4 IPs -- but for simplicity's sake, most home users (and home routers) just stick to using a whole Class-C range. Subnet masks get complicated fast when dealing with subnets that are smaller than whole Class ranges.

The VPN is able to create the link between your two VPN routers because the VPN isn't using your internal IP range (the one created by DHCP) -- it's using the external IPs (the ones given to the router by your ISPs) to make the connection between the two routers. The routers can see each other, but they can't pass traffic back and forth because without the subnets and the subnet mask set up right, they don't know what traffic stays internal and what traffic to send through the VPN. If you want both network segments to use the same Class-C range, then you'll need to decide how many IPs at each location you need, then change the settings of the routers to only use that size of subnet. If you let me know how many IPs at each location, I can send you the subnet and subnet mask numbers for them.

I use DD-WRT on all my routers (both at home and for wireless access points at work), so I'm reasonably familiar with using it. I've tried for years (no exaggeration) to try and figure out a way to VPN my house and my sister's house so we can share shows back and forth on our TiVos (she lives where I grew up and I've moved away, but I'd like to be able to watch news and local programs from there). Setting up the VPN is easy, and we can share computer files, but there is no way I've figured out yet to make the TiVos talk across the subnets.


----------



## hugetivofan (Feb 24, 2001)

Ckought, thanks again for continued replies. I think I understand now. No need for me to subdivide the Class-C if MRV is not going to work anyway. Such a shame! 

So, on to Stormspace's suggestion - thanks very much for the idea. I don't have a lot of experience with Tivo Desktop, but when I used it a couple of years ago I found it slow and difficult to manage. A few questions for you:

1) To do this, would I need always-on PCs running Tivo Desktop at both locations?
2) How does Tivo Desktop actually transfer the shows? Is there re-encoding that is happening or is it just the file itself? When I put it back on the other Tivo, would I experience any quality degradation?
3) Assuming I had the network space, how would I create a "scheduled task" to keep them all up to date?


----------



## puffdaddy (Mar 1, 2006)

I believe an Ethernet bridged OpenVPN setup will do want you want.

See their FAQ here: link and their howto here: link.


----------



## Stormspace (Apr 13, 2004)

hugetivofan said:


> So, on to Stormspace's suggestion - thanks very much for the idea. I don't have a lot of experience with Tivo Desktop, but when I used it a couple of years ago I found it slow and difficult to manage. A few questions for you:


You could also use PyTiVo or KMTTG, however TD would be the simplest to set up.



> 1) To do this, would I need always-on PCs running Tivo Desktop at both locations?


Yes. They could point to a single network location, or each point to a local folder that is synchronized with the other. In this case synchronization would just be all the files in one lump.



> 2) How does Tivo Desktop actually transfer the shows? Is there re-encoding that is happening or is it just the file itself? When I put it back on the other Tivo, would I experience any quality degradation?


As long as TiVo's with the same MAK are being used on both ends, you'll be able to use the raw files that TD transfers. These files are mpeg2 files encoded with TiVo DRM and having a .TiVo extension. TD lets you schedule automated downloads as well. So you could make certain programs auto transfer to the storage area. Quality would be the same as what you used during the recording.



> 3) Assuming I had the network space, how would I create a "scheduled task" to keep them all up to date?


If your location on house 1 was "C:\TiVo Recordings" and the other house was on "\\remotePC\TiVo Recordings" You'd do it like so.

Create a text file with a ".BAT" extension and populate it with the following lines.


```
xcopy "C:\TiVo Recordings\*.*" "\\remotePC\TiVo Recordings\" /s /d /y
xcopy "\\remotePC\TiVo Recordings\*.*" "C:\TiVo Recordings\" /s /d /y
```
of course you'd need file shares set up with the correct names.

The first line copies files to the remote area and the second copies files from the remote area. The /d switch prevents you from copying the same file more than once. You'd execute this batch file from the task scheduler in the control panel.


----------



## Stormspace (Apr 13, 2004)

Just wanted to add. A one hour show can be 1.2GB in size. Transferring that over broadband could take a while. My BB connection is only 768 up, so if I were to so the same thing it might be a couple of days before I could watch the show.


----------



## MikeAndrews (Jan 17, 2002)

Stormspace said:


> Just wanted to add. A one hour show can be 1.2GB in size. Transferring that over broadband could take a while. My BB connection is only 768 up, so if I were to so the same thing it might be a couple of days before I could watch the show.


A one hour HD show can be 5-6GB in size.

Bridging is what you would for MRV to work need but use KMTTG to transfer from offline storage as above.


----------



## Stormspace (Apr 13, 2004)

netringer said:


> A one hour HD show can be 5-6GB in size.
> 
> Bridging is what you would for MRV to work need but use KMTTG to transfer from offline storage as above.


Agree. I was referring to an SD show.


----------



## Stormspace (Apr 13, 2004)

netringer said:


> A one hour HD show can be 5-6GB in size.
> 
> Bridging is what you would for MRV to work need but use KMTTG to transfer from offline storage as above.


If he used KMTTG he could transcode the files to another format that would be smaller and transfer quicker. I'm not certain if KMTTG will automatically retranscode to Mpeg2 on the other side though.


----------



## Ckought (Nov 29, 2006)

If there's a computer you can run TiVo Desktop on in each location, then I'd go with Stormspace's suggestion -- with a slight modification.

Have one of the computers be the primary storage location for the .TiVo files. Create a share for the folder they'll be located in. Map a drive letter on both computers to that share, then set up TiVo Desktop on the two computers. Have them both point to the same mapped share as the location of their .TiVo files. That way, you won't have to transfer the files manually (or by .BAT file). For example: If you put the .TiVo files in a mapped share on a computer in Home 1, then point the TiVo Desktop in Home 2 to that mapped share, it will list those shows as if they're stored locally -- therefore, the TiVo in Home 2 will think they're local and when it requests them from the TiVo Desktop in Home 2, the TiVo Desktop in Home 2 will pull them from the mapped share located in Home 1 and then pass it to the TiVo in Home 2.

It's complicated, but easier than setting up pytivo or any of the other options. As has been noted before, don't expect to be able to watch any shows stored at the other location in real-time (unless you have a very fat pipe going out).

Also, technically, since a computer would be doing all the dirty work to compensate for TiVo's OS limitations, the files could be stored anywhere that you can map a drive letter to -- it could be a NAS, or even out in the cloud (as long as the service offered a utility to map a drive letter to it). I keep all my stuff on a 4TB NAS because it has RAID 5 so there's less of a chance of loosing my recordings.


----------



## hugetivofan (Feb 24, 2001)

I am principally trying to get the ability to transfer shows from Home 2 to Home 1. With FIOS at home 2, they claim upload speeds of 35 Mbps, so hopefully it won't take forever to transfer shows. The other way, my cable modem is ~500Kbps, so understand it would be at a snail's pace.

puffdaddy and netringer, the bridging method sounds like it may be a more direct solution (or, at least, require one less PC). I read the links you provided, but have no experience w OpenVPN. Could you give me your thoughts on how it would be configured given the comments above? I am thinking that it would be something like this:

Home 2/FIOS is primary network
Netgear VPN box installed at Home 2
Home 1 PC runs OpenVPN, connects to Home 2 VPN box
Home 1 has a switch attached to Home 1 PC, which then is attached to Tivo in Home 1
So Tivo at Home 1 gets its IP from Home 2 VPN box via Home 1 PC running OpenVPN
In this scenario I guess I would ditch the extra Netgear VPN box?

Does this make sense? Please let me know what you think.

I guess the other question is, why do you need a software bridging solution? Is this problem really so unique that no hardware configuration can solve it?


----------



## Rdian06 (Apr 12, 2008)

hugetivofan said:


> I guess the other question is, why do you need a software bridging solution? Is this problem really so unique that no hardware configuration can solve it?


It's solvable, but there are pitfalls and most of the consumer grade equipment isn't designed to handle this particular scenario.

The Tivos uses IP broadcast packets to announce themselves and to discover other Tivos and services. IP broadcast packets are dropped by most routers so effectively only computers connected to the local subnet can receive the broadcasts. Actual Now Playing list querys, MRV transfers, and Tivo guide updates happen over standard TCP so they could theoretically traverse the Internet without issue (I've never tried to query the Now Playing list from outside of the same subnet so I'm not 100% sure if the Tivo does an additional check before allowing the query. Likewise you can emulate a MRV transfer via a special URL and I've never tried to do that from outside of the local subnet either.)

But the two Tivo's have to know about each other via the discovery broadcasts before transfers can happen. And the broadcasts happen at timed intervals.

Bridging essentially takes two network segments and makes them look like one network segment without the need for IP routing. That way broadcasts are shared across the whole bridged segment and Tivo discovery will work.

Looking over the docs to the Netgear VPN routers you have, I see there essentially two types of VPN setups the box is capable of creating easily: Gateway to Gateway and Gateway to Client (using special client software running on the client PC). In Gateway to Gateway mode (which is what you had originally) each side is its own subnet and packets are IP routed through the VPN tunnel. In Gateway to Client mode, the special client software running on the PC creates a virtual network adapter that is logically on the remote subnet. Since your Tivo is not a PC, it can't run the special client software and cannot take advantage of Gateway to Client mode.

In industrial/enterprise VPN equipment, you can have VPN devices that form transparent bridge tunnels and VPN endpoint devices that do Gateway to Client mode without the need for special software (because it's built into the endpoint and only one device is allowed to plug into the endpoint at a time).

So to solve your problem, I think you're really going to need a PC running OpenVPN at both locations. The OpenVPN client cannot connect to a Netgear VPN box as far as I know.

Also, I haven't done much research into this, but I'm surprised someone hasn't created a proxy for the Tivo discovery protocol. I haven't dug deep enough into the guts of the protocol to know whether there is some technical limitation, but from a networking standpoint, I'd think it be theoretically possible.


----------



## puffdaddy (Mar 1, 2006)

OpenVPN would have to be used at both ends.

Looking at the FVS338 manual (link), it states


> The Remote LAN IP address must be in a different subnet than the Local LAN
> IP address. For example, if the local subnet is 192.168.1.x, then the remote
> subnet could be 192.168.10.x. but could not be 192.168.1.x. If this information
> is incorrect, the tunnel will fail to connect.


Perhaps they don't support bridging?


----------



## Rdian06 (Apr 12, 2008)

Hrmm, turns out there is at least one attempt at proxying the Tivo discovery protocol:

TiVoBridge
http://www.smittyware.com/linux/tivobridge/doc.php

This appears to need to run on a machine that has direct access to both subnets. So you'd need to run it (assuming you can port and compile it on Windows) on a machine that has the special Netgear software installed and configure a Gateway to Client VPN on one of your Netgear VPN boxes.

Interesting.


----------



## erikg (Aug 20, 2007)

From a networking standpoint this should work; netgears are a bit to UI friendly for setthing these types of things up. Typically in the setups we do for this type of application you're looking at a lan to lan (L2L) VPN. 

What you are doing is taking two distinct networks and making a bridge in the form of a tunnel. I would stick with the gateway setup; and actually change the subnet. I'm suggesting this for a couple of reasons; like it was said before the router isn't sure where each distinct subnet resides.

Take for instance the following:

Home1
VPN1 192.168.1.X 255.255.255.0

Home2
VPN2 192.168.2.X 255.255.255.0

Here you have two distinct private IP space which can happily concide; redoing your configuration with this the netgear should ask you what the address space is on the other side. I'm betting setting it up this way you should be even able to ping a computer on the other side once the tunnel is established. 

The problem you're going to run into again like it was already said is the Tivos use broadcast traffic directed at 192.168.1.255 on the VPN1 since its a /24 its the last IP and 192.168.2.255. The tunnel won't broadcast this traffic across to the other side because its not directional. For the netgear docs I believe you should be able to add a static route basically saying: 

Assign a static IP to each of the tivos; for instance .10 and .11:

route all traffic from 192.168.1.10 to 192.168.2.10 
route all traffic from 192.168.2.11 to 192.168.1.11

If the tivo at 192.168.1.10 communicates with 192.168.1.11 the router will route the traffic across the bridge to the IP 192.168.2.11. Any traffic from 192.168.2.11 to 192.168.2.10 would be sent via the tunnel to 192.168.1.10.

Basically what you're doing is forwarding traffic; I know on a cisco asa you can configure this by adding a route; linux you can as well but somewhere in that UI you would need to find the option to forward the traffic. In some distros I think even DDwrt you can port forward which may do it; port forward all traffic for HME etc to the remote IP. 

Good luck.


----------



## Rdian06 (Apr 12, 2008)

erikg said:


> The problem you're going to run into again like it was already said is the Tivos use broadcast traffic directed at 192.168.1.255 on the VPN1 since its a /24 its the last IP and 192.168.2.255. The tunnel won't broadcast this traffic across to the other side because its not directional. For the netgear docs I believe you should be able to add a static route basically saying:
> 
> Assign a static IP to each of the tivos; for instance .10 and .11:
> 
> ...


If I'm reading those static routes correctly, they would effectively prevent the Tivos from talking to anything besides the other Tivo. That would break the Tivos checking in with tivo.com. You'd need to be more specific with your routing rule to only do this with broadcasts to the specific port and unicast traffic destined to the other Tivo.

Also, for the mDNS (Zeroconf) broadcasts, apparently the Tivo will ignore the beacons if the source address isn't from the same subnet so forwarding the packet without more massaging may not work.


----------



## Ckought (Nov 29, 2006)

If he gets routers that support the full version of DD-WRT, he can run OpenVPN from router-to-router. Since DD-WRT is Linux based, it has full programming capabilities in order to create route tables.

I've never set up OpenVPN and have only done basic route tables, so it'd be up to someone with more experience to configure it -- but, DD-WRT should have all the tools needed if there's someone out there that knows how to set them up.


----------



## hugetivofan (Feb 24, 2001)

Thanks for so many suggestions everyone! I have to say my head is spinning from the complexity involved. I was trying to set up erikg's solution last night, but I came across a different, non-Tivo problem. The netgear vpn boxes will not establish an IPSec connection using the addressing scheme erikg details. Oddly, they will establish an IPSec connection using my original setup (192.168.1.10 for box 1 and 192.168.1.11 for box 2), seemingly in direct conflict with the netgear manual as noted by puffdaddy. however, the VPN under this scenario is useless as CKought points out - the packets seem like they dont know where to go and I can't ping across homes.

Any ideas on what is wrong here?


----------



## hugetivofan (Feb 24, 2001)

If helpful, here is what the VPN log on the netgear router says when I have the second addressing scheme:

2010 Jul 13 11:18:02 [FVS338] [IKE] accept a request to establish IKE-SA: [Home2DNS]_
2010 Jul 13 11:18:02 [FVS338] [IKE] remote configuration for identifier "[Home2DNS]" found_
2010 Jul 13 11:18:02 [FVS338] [IKE] Initiating new phase 1 negotiation: [Home1IP][500]<=>[Home2IP][500]_
2010 Jul 13 11:18:02 [FVS338] [IKE] Beginning Identity Protection mode._
2010 Jul 13 11:18:02 [FVS338] [IKE] Setting DPD Vendor ID_
2010 Jul 13 11:18:02 [FVS338] [IKE] Received Vendor ID: RFC XXXX_
2010 Jul 13 11:18:02 [FVS338] [IKE] Received Vendor ID: DPD_
2010 Jul 13 11:18:02 [FVS338] [IKE] DPD is Enabled_
2010 Jul 13 11:18:02 [FVS338] [IKE] Received Vendor ID: KAME/racoon_
2010 Jul 13 11:18:02 [FVS338] [IKE] For [Home2IP][500], Selected NAT-T version: RFC XXXX_
2010 Jul 13 11:18:02 [FVS338] [IKE] Received Vendor ID: KAME/racoon_
2010 Jul 13 11:18:02 [FVS338] [IKE] NAT-D payload matches for [Home1IP][500]_
2010 Jul 13 11:18:02 [FVS338] [IKE] NAT-D payload does not match for [Home2IP][500]_
2010 Jul 13 11:18:02 [FVS338] [IKE] NAT detected: PEER_
2010 Jul 13 11:18:02 [FVS338] [IKE] for debugging :: changing ports
2010 Jul 13 11:18:02 [FVS338] [IKE] port changed !!_
2010 Jul 13 11:18:03 [FVS338] [IKE] ISAKMP-SA established for [Home1IP][4500]-[Home2IP][4500] with spi:[long string of characters;not sure if this is sensitive so deleting]_
2010 Jul 13 11:18:03 [FVS338] [IKE] Sending Informational Exchange: notify payload[INITIAL-CONTACT]_
2010 Jul 13 11:18:04 [FVS338] [IKE] Initiating new phase 2 negotiation: [Home1IP][500]<=>[Home2IP][0]_
2010 Jul 13 11:18:04 [FVS338] [IKE] Adjusting encryption mode to use UDP encapsulation_
2010 Jul 13 11:18:05 [FVS338] [IKE] Adjusting peer's encmode 3(3)->Tunnel(1)_
2010 Jul 13 11:18:05 [FVS338] [IKE] IPsec-SA established[UDP encap 4500->4500]: ESP/Tunnel [Home2IP]->[Home1IP] with spi=[second string of characters]
2010 Jul 13 11:18:05 [FVS338] [IKE] IPsec-SA established[UDP encap 4500->4500]: ESP/Tunnel [Home1IP]->[Home2IP] with spi=[second string of characters]

Here is the VPN log using erikg's addressing scheme

2010 Jul 13 12:31:36 [FVS338] [IKE] Using IPsec SA configuration: 192.168.2.0/24<->192.168.1.10/24_
2010 Jul 13 12:31:36 [FVS338] [IKE] remote configuration for identifier "[Home2DNS]" found_
2010 Jul 13 12:31:36 [FVS338] [IKE] Initiating new phase 1 negotiation: [Home1IP][500]<=>[Home2IP][500]_
2010 Jul 13 12:31:36 [FVS338] [IKE] Beginning Identity Protection mode._
2010 Jul 13 12:31:36 [FVS338] [IKE] Setting DPD Vendor ID_
2010 Jul 13 12:31:37 [FVS338] [IKE] Received Vendor ID: RFC XXXX_
2010 Jul 13 12:31:37 [FVS338] [IKE] Received Vendor ID: DPD_
2010 Jul 13 12:31:37 [FVS338] [IKE] DPD is Enabled_
2010 Jul 13 12:31:37 [FVS338] [IKE] Received Vendor ID: KAME/racoon_
2010 Jul 13 12:31:37 [FVS338] [IKE] For [Home2IP][500], Selected NAT-T version: RFC XXXX_
2010 Jul 13 12:31:37 [FVS338] [IKE] Received Vendor ID: KAME/racoon_
2010 Jul 13 12:31:37 [FVS338] [IKE] NAT-D payload matches for [Home1IP][500]_
2010 Jul 13 12:31:37 [FVS338] [IKE] NAT-D payload does not match for [Home2IP][500]_
2010 Jul 13 12:31:37 [FVS338] [IKE] NAT detected: PEER_
2010 Jul 13 12:31:37 [FVS338] [IKE] for debugging :: changing ports
2010 Jul 13 12:31:37 [FVS338] [IKE] port changed !!_
2010 Jul 13 12:31:38 [FVS338] [IKE] ISAKMP-SA established for [Home1IP][4500]-[Home2IP][4500] with spi:[long character string]
2010 Jul 13 12:31:38 [FVS338] [IKE] Sending Informational Exchange: notify payload[INITIAL-CONTACT]_
2010 Jul 13 12:31:39 [FVS338] [IKE] Initiating new phase 2 negotiation: [Home1IP][0]<=>[Home2IP][0]_
2010 Jul 13 12:31:39 [FVS338] [IKE] Adjusting encryption mode to use UDP encapsulation_
2010 Jul 13 12:31:42 [FVS338] [IKE] accept a request to establish IKE-SA: [Home2DNS]_
2010 Jul 13 12:31:42 [FVS338] [IKE] remote configuration for identifier "[Home2DNS]" found_
2010 Jul 13 12:31:42 [FVS338] [IKE] Initiating new phase 2 negotiation: [Home1IP][500]<=>[Home2IP][0]_
2010 Jul 13 12:31:42 [FVS338] [IKE] Adjusting encryption mode to use UDP encapsulation_
2010 Jul 13 12:31:51 [FVS338] [IKE] accept a request to establish IKE-SA: [Home2DNS]_
2010 Jul 13 12:31:51 [FVS338] [IKE] remote configuration for identifier "[Home2DNS]" found_
2010 Jul 13 12:31:51 [FVS338] [IKE] Initiating new phase 2 negotiation: [Home1IP][500]<=>[Home2IP][0]_
2010 Jul 13 12:31:51 [FVS338] [IKE] Adjusting encryption mode to use UDP encapsulation_
2010 Jul 13 12:32:39 [FVS338] [IKE] Phase 2 negotiation failed due to time up. [second long character string]
2010 Jul 13 12:32:39 [FVS338] [IKE] an undead schedule has been deleted: 'quick_i1prep'._
2010 Jul 13 12:32:42 [FVS338] [IKE] Phase 2 negotiation failed due to time up. [2nd long character string]
2010 Jul 13 12:32:42 [FVS338] [IKE] an undead schedule has been deleted: 'quick_i1prep'._

Here is my VPN Policy page with the erikg setup. Couldnt get the entire screen for the screenshot, below the bottom it just specified which IKE policy to use, which is the same name as the VPN policy name. I deleted specific DNS and IP stuff (not sure if necessary, but figured not a bad thing to do):

http://img401.imageshack.us/i/ikepolicy.png/

Here is my IKE Policy page:

http://img401.imageshack.us/i/ikepolicy.png/

Sorry for the data dump, but I assume it may be helpful in figuring out what is going on. Thanks for any help!


----------



## shaown (Jul 1, 2002)

Hugetivofan - did you ever get this to work?


----------



## hugetivofan (Feb 24, 2001)

shaown, just sent you a pm


----------



## MurrayJimW (Apr 21, 2004)

hugetivofan said:


> shaown, just sent you a pm


Well dang - I'm interested in this too!!!


----------

