Watchguard FB700 Branch VPN Issue
in [Firewalls]
|
Prev: Watchguard Firewall - Request Denied ??
Next: Do u have on comp.os.ms-windows.nt.admin.networking. There is the solution
From: mhager on 13 Apr 2008 12:30 Hello, I have an issue with a VPN tunnel that has worked fine for 4 years until this week. The tunnel is a one way tunnel. The boxes are both Watchguard 700's. Ping is enabled on the remote firewall. When I ping the trusted interface on the remote box, 10.x.x.253, it responds. When I ping the machine 10.x.x.140 no respond. The machine is on and functioning. Now I noticed some wired things in the logs. Here are the logs from the remote firebox: 04/12/08 18:18 iked[133]: FROM 66.184.x.x IF-HDR* -C9279D04 ISA_HASH 04/12/08 18:18 iked[133]: Received a packet for an unknown SA 04/12/08 18:21 dvcpd[119]: opening dvcp server 66.184.x.x with client id DGJ 04/12/08 18:21 dvcpd[119]: Read error from 66.184.x.x : Connection refused 04/12/08 18:21 dvcpd[119]: config file has not changed since last dvcp update 04/12/08 18:21 dvcpd[119]: server will be contacted in 1800 seconds 04/12/08 18:21 iked[133]: FROM 66.184.x.x IF-HDR* -5B98261D ISA_HASH 04/12/08 18:21 iked[133]: Received a packet for an unknown SA 04/12/08 18:22 iked[133]: FROM 66.184.x.x MM-HDR ISA_SA ISA_VENDORID ISA_VENDORID ISA_VENDORID ISA_VENDORID 04/12/08 18:22 iked[133]: TO 66.184.x.x MM-HDR ISA_SA ISA_VENDORID ISA_VENDORID 04/12/08 18:22 iked[133]: FROM 66.184.x.x MM-HDR ISA_KE ISA_NONCE NAT-D NAT-D 04/12/08 18:22 iked[133]: TO 66.184.x.x MM-HDR ISA_KE ISA_NONCE NAT-D NAT-D 04/12/08 18:22 iked[133]: CRYPTO ACTIVE after delay 04/12/08 18:22 iked[133]: FROM 66.184.x.x MM-HDR* ISA_ID ISA_HASH 04/12/08 18:22 iked[133]: TO 66.184.x.x MM-HDR* ISA_ID ISA_HASH 04/12/08 18:22 iked[133]: FROM 66.184.x.x IF-HDR* -43BD09B5 ISA_HASH ISA_NOTIFY 04/12/08 18:22 iked[133]: Received INITIAL_CONTACT message, mess_id=0xB509BD43 04/12/08 18:22 iked[133]: FROM 66.184.x.x QM-HDR* -5D1E747E ISA_HASH ISA_SA ISA_NONCE ISA_ID ISA_ID 04/12/08 18:22 iked[133]: TO 66.184.x.x QM-HDR* -5D1E747E ISA_HASH ISA_SA ISA_NONCE ISA_ID ISA_ID 04/12/08 18:22 iked[133]: FROM 66.184.x.x QM-HDR* -5D1E747E ISA_HASH 04/12/08 18:22 iked[133]: Load outbound ESP SA, Algs=ESP_DES/ AUTH_ALG_HMAC_SHA1 Life=0sec/0KB SPI=1404194A 04/12/08 18:22 iked[133]: Load inbound ESP SA, Algs=ESP_DES/ AUTH_ALG_HMAC_SHA1 Life=0sec/0KB SPI=12042074 04/12/08 18:22 iked[133]: Tunnel created for 10.x.x.0/24 <-> 10.x.x.0/14 04/12/08 18:22 kernel: ipsec: make bundle for channel 14, 1 in SA's, 1 out SA's 04/12/08 18:25 iked[133]: FROM 66.184.x.x IF-HDR* -5E28E4FC ISA_HASH ISA_NOTIFY 04/12/08 18:25 iked[133]: Received KEEPALIVE_REQUEST message, mess_id=0xFCE4285E 04/12/08 18:25 iked[133]: Sending KEEPALIVE_ACK message 04/12/08 18:25 iked[133]: TO 66.184.x.x IF-HDR* -7CD567A1 ISA_HASH ISA_NOTIFY 04/12/08 18:25 iked[133]: TO 66.184.x.x IF-HDR* -7CD567A1 ISA_HASH ISA_NOTIFY 04/12/08 18:28 iked[133]: FROM 66.184.x.x IF-HDR* -0E19F640 ISA_HASH ISA_NOTIFY 04/12/08 18:28 iked[133]: Received KEEPALIVE_REQUEST message, mess_id=0x40F6190E 04/12/08 18:28 iked[133]: Sending KEEPALIVE_ACK message 04/12/08 18:28 iked[133]: TO 66.184x.x IF-HDR* -E675CDAD ISA_HASH ISA_NOTIFY 04/12/08 18:31 iked[133]: FROM 66.184.x.x IF-HDR* -0762ACC7 ISA_HASH ISA_NOTIFY 04/12/08 18:31 iked[133]: Received KEEPALIVE_REQUEST message, mess_id=0xC7AC6207 04/12/08 18:31 iked[133]: Sending KEEPALIVE_ACK message 04/12/08 18:31 iked[133]: TO 66.184.x.x IF-HDR* -55D1BF24 ISA_HASH ISA_NOTIFY 04/12/08 18:34 iked[133]: FROM 66.184.x.x IF-HDR* -459D6CAB ISA_HASH ISA_NOTIFY 04/12/08 18:34 iked[133]: Received KEEPALIVE_REQUEST message, mess_id=0xAB6C9D45 04/12/08 18:34 iked[133]: Sending KEEPALIVE_ACK message 04/12/08 18:34 iked[133]: TO 66.184.x.x IF-HDR* -FE956D35 ISA_HASH ISA_NOTIFY 04/12/08 18:37 iked[133]: FROM 66.184.x.x IF-HDR* -2460B6DE ISA_HASH ISA_NOTIFY 04/12/08 18:37 iked[133]: Received KEEPALIVE_REQUEST message, mess_id=0xDEB66024 04/12/08 18:37 iked[133]: Sending KEEPALIVE_ACK message 04/12/08 18:37 iked[133]: TO 66.184.x.x IF-HDR* -5F5BE769 ISA_HASH ISA_NOTIFY I'm thinking it's an encryption problem, but I'm not sure. Thanks for any help
From: Leythos on 13 Apr 2008 20:30 In article <6e5441de-35c7-41f4-8ac0-a66b9f8d8df5 @a1g2000hsb.googlegroups.com>, mhager(a)frenchcreekcomp.com says... > Hello, > > I have an issue with a VPN tunnel that has worked fine for 4 years > until this week. The tunnel is a one way tunnel. The boxes are both > Watchguard 700's. Ping is enabled on the remote firewall. > When I ping the trusted interface on the remote box, 10.x.x.253, it > responds. When I ping the machine 10.x.x.140 no respond. The machine > is on and functioning. Now I noticed some wired things in the logs. > Here are the logs from the remote firebox: Generate new certificates for both fireboxes and see if that fixes it. -- - Igitur qui desiderat pacem, praeparet bellum. - Calling an illegal alien an "undocumented worker" is like calling a drug dealer an "unlicensed pharmacist" spam999free(a)rrohio.com (remove 999 for proper email address)
From: mmadd29 on 14 Apr 2008 12:14 On Apr 13, 8:30 pm, Leythos <v...(a)nowhere.lan> wrote: > In article <6e5441de-35c7-41f4-8ac0-a66b9f8d8df5 > @a1g2000hsb.googlegroups.com>, mha...(a)frenchcreekcomp.com says... > > > Hello, > > > I have an issue with a VPN tunnel that has worked fine for 4 years > > until this week. The tunnel is a one way tunnel. The boxes are both > > Watchguard 700's. Ping is enabled on the remote firewall. > > When I ping the trusted interface on the remote box, 10.x.x.253, it > > responds. When I ping the machine 10.x.x.140 no respond. The machine > > is on and functioning. Now I noticed some wired things in the logs. > > Here are the logs from the remote firebox: > > Generate new certificates for both fireboxes and see if that fixes it. > > -- > - Igitur qui desiderat pacem, praeparet bellum. > - Calling an illegal alien an "undocumented worker" is like calling a > drug dealer an "unlicensed pharmacist" > spam999f...(a)rrohio.com (remove 999 for proper email address) Hi, Thanks for the response. I'm not using certs, I'm using a shared secret. Should I dump the shared secret for a cert? Thanks
From: Leythos on 14 Apr 2008 12:42
In article <d71a926c-a141-486b-bbef-e6b8b7b1c0e5 @a70g2000hsh.googlegroups.com>, mhager(a)frenchcreekcomp.com says... > On Apr 13, 8:30 pm, Leythos <v...(a)nowhere.lan> wrote: > > In article <6e5441de-35c7-41f4-8ac0-a66b9f8d8df5 > > @a1g2000hsb.googlegroups.com>, mha...(a)frenchcreekcomp.com says... > > > > > Hello, > > > > > I have an issue with a VPN tunnel that has worked fine for 4 years > > > until this week. The tunnel is a one way tunnel. The boxes are both > > > Watchguard 700's. Ping is enabled on the remote firewall. > > > When I ping the trusted interface on the remote box, 10.x.x.253, it > > > responds. When I ping the machine 10.x.x.140 no respond. The machine > > > is on and functioning. Now I noticed some wired things in the logs. > > > Here are the logs from the remote firebox: > > > > Generate new certificates for both fireboxes and see if that fixes it. > > > > Hi, > > Thanks for the response. I'm not using certs, I'm using a shared > secret. > > Should I dump the shared secret for a cert? I use shared keys also, but I believe that the firebox has a built-in certificate for branch office tunnels - I could be wrong, but it's worth a shot. You could also have that machine with a bad default-gateway address. As an example, we had a person install a printer at 10.38.0.200 with a gateway of 10.8.0.1 when it should have been 10.38.0.1. They could print to the printer on their local network, but it would not route via the firewall/VPN's and we could not reach it remotely - when the GW was reset it worked perfectly - as one would expect. Check your default gateway on the system in question. -- - Igitur qui desiderat pacem, praeparet bellum. - Calling an illegal alien an "undocumented worker" is like calling a drug dealer an "unlicensed pharmacist" spam999free(a)rrohio.com (remove 999 for proper email address) |