 robroth
join:2005-04-16 Newburyport, MA
| ZyWall 35 to ZyWall 35 VPN
Could someone please point me in the direction of documentation for setting up a router to router VPN? I have never set up a VPN of this type before with any hardware. I'll be flying down to a new remote office location next week and want to make sure I'm prepared when I get there rather than banging my head against a wall. If possible I'd like to configure the one at my office before I go down there (the ZyXel down there is currently sitting in a box though and I have no idea what the IP address will be yet).
If possible, I would like to avoid having to use any sort of certificate. While they may be more secure, they are nothing but headaches and introduce far too many complexities.
Thanks! |
|
 superataru
join:2004-12-07 07100 | have a look . .. to »ftp://ftp.zyxel.com/ZyWALL_35_UTM/user_guide/ |
|
 dslpartner
join:2005-02-18 | reply to robroth The manual and support notes used to be on the cd that came with the device. -- "Perl is executable line noise, Python is executable pseudo-code." |
|
 fox7
join:2001-02-12 Culver City, CA
| reply to robroth You might consider for a temporary basis setting up the Zywall, where you are leaving from, to permit remote log-in so you can play with the settings when you are at the distant location. If you have someone to work with, you at one end, they at the other, you won't need this.
Having the same manufacturer at both ends makes it the easiest. You have one set of vocabulary, and the screens will be the same with both units.
fox7 |
|
 robroth
join:2005-04-16 Newburyport, MA
| reply to robroth ok, so i'm now at the remote office and i'm trying to set up the vpn between the two zywall 35s.
i can ping the WAN address of each zywall from each location. i created a VPN rule (IKE) on each router using - my address 0.0.0.0 (per the docs this will default to the local address) - primary remote gateway (the WAN address of the other router) - pre-shared key (entered the same password on both ends) everything else i used default settings for
then i created a network policy rule under each VPN rule - marked as active - allow netbios traffic through ipsec tunnel - local network uses subnet address (192.168.1.0/255.255.255.0) on one end, (192.168.10.0/255.255.255.0) on the other everything else is default
i then click the 'connect' icon
it tries to connect a couple of times then says
VPN Tunnel Establishment Failed The VPN tunnel establishment has failed! Please click Return and check the VPN rule information in the previous screen. Please also refer to Logs for the reason of the failure.
the logs just show: 1 2001-05-04 13:01:12 IKE Packet Retransmit 66.93.xxx.xxx 64.140.xxx.xxx IKE 2 2001-05-04 13:01:12 The cookie pair is : 0x9B2ADB64836ED99E / 0x0000000000000000 66.93.xxx.xxx 64.140.xxx.xxx IKE 3 2001-05-04 13:01:08 IKE Negotiation is in process 66.93.xxx.xxx 64.140.xxx.xxx IKE 4 2001-05-04 13:01:08 The cookie pair is : 0x9B2ADB64836ED99E / 0x0000000000000000 66.93.xxx.xxx 64.140.xxx.xxx IKE 5 2001-05-04 13:01:08 Send:[SA][VID][VID] 66.93.xxx.xxx 64.140.xxx.xxx IKE 6 2001-05-04 13:01:08 The cookie pair is : 0x9B2ADB64836ED99E / 0x0000000000000000 66.93.xxx.xxx 64.140.xxx.xxx IKE 7 2001-05-04 13:01:08 Send Main Mode request to [64.140.xxx.xxx] 66.93.xxx.xxx 64.140.xxx.xxx IKE 8 2001-05-04 13:01:08 Rule [richmond.to.boston] Sending IKE request 66.93.xxx.xxx 64.140.xxx.xxx IKE 9 2001-05-04 13:01:08 The cookie pair is : 0x9B2ADB64836ED99E / 0x0000000000000000 66.93.xxx.xxx 64.140.xxx.xxx IKE 10 2001-05-04 13:01:08 Rule [richmond.to.boston] IKE packet retransmit count reached IPSEC
any ideas where to go from here for troubleshooting? mucho thanks! |
|
 dslpartner
join:2005-02-18
| You need to look at the logs on both sides at the same time. From what I can see, your log is from the intiating side and its hard to say if you actually get your traffic across to the other gw correctly.
Check that your receving gw actually gets the main mode requests etc, this will be shown in the logs. In addition to what it thinks is wrong. -- "Perl is executable line noise, Python is executable pseudo-code." |
|
 robroth
join:2005-04-16 Newburyport, MA
| The remote log just shows
1 2008-07-17 11:13:03 IKE Packet Retransmit 74.92.xxx.xxx 66.93.xxx.xxx IKE 2 2008-07-17 11:13:03 The cookie pair is : 0x488C4C12328297C0 / 0x0000000000000000 74.92.xxx.xxx 66.93.xxx.xxx IKE 3 2008-07-17 11:12:47 IKE Packet Retransmit 74.92.xxx.xxx 66.93.xxx.xxx IKE 4 2008-07-17 11:12:47 The cookie pair is : 0x488C4C12328297C0 / 0x0000000000000000 74.92.xxx.xxx 66.93.xxx.xxx IKE |
|
 dslpartner
join:2005-02-18
| Does not look like the traffic arrives at the remote gateway. If you compare the ip addresses you will see that the remote is reporting 74.92.xxx.xxx and 66.93.xxx.xxx and the initiater is reporting 66.93.xxx.xxx and 64.140.xxx.xxx
The ip ranges on the LAN's are not overlapping between the 74.92.xxx.xxx and 66.93.xxx.xxx tunnel and the 64.140.xxx.xxx and 66.93.xxx.xxx tunnel. -- "Perl is executable line noise, Python is executable pseudo-code." |
|
 robroth
join:2005-04-16 Newburyport, MA | reply to robroth The remote router is dual WAN, the 74.92 IP is the address of the 2nd WAN interface where I was attempting to connect to the first. Let me try the other IP and also try to initiate the connect from the dual wan router.
sigh... no love.... |
|
 robroth
join:2005-04-16 Newburyport, MA
| Well, I'm back to working on this. I'm pretty much done setting up everything else down here (Asterisk was NOT fun and consumed almost my entire day). This isn't essential but sure would be nice if these guys could access our Exchange server directly over VPN rather than via OWA as they've been doing for 2 years. |
|
 robroth
join:2005-04-16 Newburyport, MA
edit: July 17th, @04:42PM
| reply to robroth ZyXel has had two techs remote in to both routers and can't figure out why it's not working. Tech 1 had me flash the firmware on both, I called them back after that didn't resolve the problem and tech 2 deleted and recreated the VPN configs.
They've escalated to tier 2 who is now trying to build a VPN between each of my routers and one of theirs to help identify where the problem is.
Glad it's not just me being clueless . Actually after playing with this all day, I've learned quite a bit and am not so clueless as I was yesterday. |
|
 robroth
join:2005-04-16 Newburyport, MA
| reply to robroth I now have the VPN connected. Turn out port 500 was forwarded on one of the routers. Once I disabled that, they connected fine.
I now have to figure out why I can't ping any machines on the remote network.
Ie, Im on a machine on 192.168.1.0/255.255.255.0 network and try to ping 192.168.10.200 on the remote network and it just times out. I have the VPN configured as subnet to subnet, ports are defaulted 0 to 0. |
|
 robroth
join:2005-04-16 Newburyport, MA
| reply to robroth hmmm, reading through the docs it seems I may actually have to set up some sort of port forwarding rules to be able to have peer to peer connectivity over the VPN. I figured it was just like having everything on the local network. Eesh, this is going to get complicated if that's the case. |
|
 dslpartner
join:2005-02-18
| reply to robroth said by robroth :I now have the VPN connected. Turn out port 500 was forwarded on one of the routers. Once I disabled that, they connected fine. I now have to figure out why I can't ping any machines on the remote network. Ie, Im on a machine on 192.168.1.0/255.255.255.0 network and try to ping 192.168.10.200 on the remote network and it just times out. I have the VPN configured as subnet to subnet, ports are defaulted 0 to 0. The host you are trying to ping on the remote lan, does it have the lan ip of the gw on the remote lan as its default gw? If not you need to make a static route from the default gw to the lan side of the remote vpn gw. Or if its just one host that you need to access, you can make a static route on that machine. |
|
 robroth
join:2005-04-16 Newburyport, MA
| I had to read what you said a few times to try and digest it all, but I believe the answer is yes, that the remote host does have the remote gw lan ip as the default gateway.
The local LAN is 192.168.1.0/24 The remote LAN is 192.168.10.0/24
From 192.168.1.40, I'm trying to ping and tracert 192.168.10.200 and it's timing out.
If I go to 192.168.10.200 and do an ipconfig:
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : companyname.com IP Address. . . . . . . . . . . . : 192.168.10.200 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.10.1
And the remote ZyXel LAN IP is 192.168.10.1 |
|
 robroth
join:2005-04-16 Newburyport, MA
edit: July 17th, @10:24PM
| Hey, how about that, I can ping from the 192.168.10.0 side to the 192.168.1.0 side. I hadn't tried that yet, but I'm happy to see it works without any tricks (the 10.0 side is my office so that means I can support them remotely. Now if I can get it working in the other direction, they can get to the Exchange server).
I can't retest the other way since I don't have a permanent PC up and running on the 1.0 side I can connect to at the moment and I'm sitting in a hotel.
Thanks for all the help BTW, it's been a crazy 2 days, tomorrow I'm wrapping things up and flying back home.
C:\tftproot>ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : companyname.com IP Address. . . . . . . . . . . . : 192.168.10.200 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.10.1
C:\tftproot>ping 192.168.1.40
Pinging 192.168.1.40 with 32 bytes of data:
Reply from 192.168.1.40: bytes=32 time=47ms TTL=62 Reply from 192.168.1.40: bytes=32 time=47ms TTL=62 Reply from 192.168.1.40: bytes=32 time=48ms TTL=62 Reply from 192.168.1.40: bytes=32 time=45ms TTL=62
Ping statistics for 192.168.1.40: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 45ms, Maximum = 48ms, Average = 46ms
|
|
 robroth
join:2005-04-16 Newburyport, MA
| There's something really funky going on here. I'm back at the remote office. Check this out, this was all done within 30 seconds.
NetBIOS over TCP/IP through the VPN is enabled. \\PDC is the netbios name of one of the servers back in my Boston office.
C:\>ping pdc
Pinging pdc [192.168.10.200] with 32 bytes of data:
Reply from 192.168.10.200: bytes=32 time=46ms TTL=126 Reply from 192.168.10.200: bytes=32 time=42ms TTL=126 Reply from 192.168.10.200: bytes=32 time=89ms TTL=126 Reply from 192.168.10.200: bytes=32 time=43ms TTL=126
Ping statistics for 192.168.10.200: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 42ms, Maximum = 89ms, Average = 55ms
C:\>ping 192.168.10.200
Pinging 192.168.10.200 with 32 bytes of data:
Request timed out. Request timed out. Request timed out. Request timed out.
Ping statistics for 192.168.10.200: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>ping pdc
Pinging pdc [192.168.10.200] with 32 bytes of data:
Request timed out. Request timed out. Request timed out. Request timed out.
Ping statistics for 192.168.10.200: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>
5 minutes later......
C:\>tracert -d 192.168.10.200
Tracing route to 192.168.10.200 over a maximum of 30 hops
1 1 ms 1 ms 1 ms 192.168.1.1 2 * * * Request timed out. 3 47 ms 48 ms 45 ms 192.168.10.200
Trace complete.
C:\>ping 192.168.10.200
Pinging 192.168.10.200 with 32 bytes of data:
Reply from 192.168.10.200: bytes=32 time=45ms TTL=126 Reply from 192.168.10.200: bytes=32 time=52ms TTL=126 Reply from 192.168.10.200: bytes=32 time=43ms TTL=126 Reply from 192.168.10.200: bytes=32 time=44ms TTL=126
Ping statistics for 192.168.10.200: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 43ms, Maximum = 52ms, Average = 46ms |
|
 robroth
join:2005-04-16 Newburyport, MA
| I tried this same experiment with the remote gateway as well to eliminate the unlikely scenario where it was a problem with the remote server. The SA monitor shows the VPN as up. In a few minutes it will likely work again.
C:\>ping 192.168.10.1
Pinging 192.168.10.1 with 32 bytes of data:
Request timed out. Request timed out. Request timed out. Request timed out.
Ping statistics for 192.168.10.1: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), |
|