ZyXel UTM Site-to-Site VPN advice?

Hi, did you get the tunnel up and running?
I also need to make a tunnel between a Zywall and an Astaro (V8 in this case). Found that an KB article 120018 should explain how, but I can't find that document. Does Astaro delete documents when they are old, or do I search the wrong way? 

Best regards
Andreas

I was able to get it mostly working.   In the site-to-site vpn, it shows two connection blocks.   The top block shows as 'error no connection', the bottom half shows as up and working.   It in fact seems to work, I can connect from and to the site.   I am just not sure why the top half shows the no connection error.     

This is what my site-to-site screen looks like in the Astaro

myvpn [1 of 2 IPsec SAs established]
SA: y.y.y.y/16=x.x.x.x x.x.x.x=x.x.x.x/32
VPN ID: x.x.x.x
Error: No connection
SA: y.y.y.y/16=x.x.x.x x.x.x.x=y.y.y.y/24
VPN ID: x.x.x.x
IKE: Auth PSK / Enc AES_CBC_128 / Hash HMAC_SHA1 / Lifetime 86400s / DPD
ESP: Enc AES_CBC_128 / Hash HMAC_SHA1 / Lifetime 28800s

Thank you,

Strange error you get, but you can connect to networkshares over the tunnel?
Would it be possible to send the zyxel configuration as well?
I have tried a little, but get a couple of error messages in the Astaro log when I try to connect. And the tunnel does not connect at all.
This is the log that I get, maybe someone else also has comments on this:

2013:06:13-16:22:11 *** pluto[13555]: packet from 83.250.***.***:500: ignoring Vendor ID payload [f758f22668750f03b08df6ebe1******] 
2013:06:13-16:22:11 *** pluto[13555]: packet from 83.250.***.***:500: ignoring Vendor ID payload [afcad71368a1f1c96b8696******] 
2013:06:13-16:22:11 *** pluto[13555]: packet from 83.250.***.***:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] 
2013:06:13-16:22:11 *** pluto[13555]: packet from 83.250.***.***:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] 
2013:06:13-16:22:11 *** pluto[13555]: packet from 83.250.***.***:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] 
2013:06:13-16:22:11 *** pluto[13555]: packet from 83.250.***.***:500: received Vendor ID payload [RFC 3947] 
2013:06:13-16:22:11 *** pluto[13555]: packet from 83.250.***.***:500: received Vendor ID payload [Dead Peer Detection] 
2013:06:13-16:22:11 *** pluto[13555]: packet from 83.250.***.***:500: ignoring Vendor ID payload [afcad71368a1f1c96b8696******] 
2013:06:13-16:22:11 *** pluto[13555]: "S_***_tunnel"[59] 83.250.***.*** #30: responding to Main Mode from unknown peer 83.250.***.*** 
2013:06:13-16:22:12 *** pluto[13555]: "S_***_tunnel"[59] 83.250.***.*** #30: NAT-Traversal: Result using RFC 3947: no NAT detected 
2013:06:13-16:22:12 *** pluto[13555]: "S_***_tunnel"[59] 83.250.***.*** #30: ignoring informational payload, type IPSEC_INITIAL_CONTACT 
2013:06:13-16:22:12 *** pluto[13555]: "S_***_tunnel"[59] 83.250.***.*** #30: Peer ID is ID_USER_FQDN: '***@***.se' 
2013:06:13-16:22:12 *** pluto[13555]: "S_***_tunnel"[60] 83.250.***.*** #30: deleting connection "S_***_tunnel"[59] instance with peer 83.250.***.*** {isakmp=#0/ipsec=#0} 
2013:06:13-16:22:12 *** pluto[13555]: "S_***_tunnel"[60] 83.250.***.*** #30: Dead Peer Detection (RFC 3706) enabled 
2013:06:13-16:22:12 *** pluto[13555]: "S_***_tunnel"[60] 83.250.***.*** #30: sent MR3, ISAKMP SA established 
2013:06:13-16:22:12 *** pluto[13555]: "S_***_tunnel"[60] 83.250.***.*** #30: received Delete SA payload: deleting ISAKMP State #30 
2013:06:13-16:22:12 *** pluto[13555]: "S_***_tunnel"[60] 83.250.***.***: deleting connection "S_***_tunnel"[60] instance with peer 83.250.***.*** {isakmp=#0/ipsec=#0} 
2013:06:13-16:22:12 *** pluto[13555]: packet from 83.250.***.***:500: Informational Exchange is for an unknown (expired?) SA 
2013:06:13-16:22:12 *** pluto[13555]: packet from 83.250.***.***:500: Informational Exchange is for an unknown (expired?) SA

Looks like a mixup between Peer ID as ID_USER_FQDN and IP address

Hi,

I am sorry, I changed some customer specific data in the log I posted. Here is a less modified version:

2013:06:13-16:22:33 oc23 pluto[30165]: packet from 83.250.111.111:500: ignoring Vendor ID payload [f758f22668750f03b08df6ebe1******] 
2013:06:13-16:22:33 oc23 pluto[30165]: packet from 83.250.111.111:500: ignoring Vendor ID payload [afcad71368a1f1c96b8696******] 
2013:06:13-16:22:33 oc23 pluto[30165]: packet from 83.250.111.111:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] 
2013:06:13-16:22:33 oc23 pluto[30165]: packet from 83.250.111.111:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] 
2013:06:13-16:22:33 oc23 pluto[30165]: packet from 83.250.111.111:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] 
2013:06:13-16:22:33 oc23 pluto[30165]: packet from 83.250.111.111:500: received Vendor ID payload [RFC 3947] 
2013:06:13-16:22:33 oc23 pluto[30165]: packet from 83.250.111.111:500: received Vendor ID payload [Dead Peer Detection] 
2013:06:13-16:22:33 oc23 pluto[30165]: packet from 83.250.111.111:500: ignoring Vendor ID payload [afcad71368a1f1c96b8696******] 
2013:06:13-16:22:33 oc23 pluto[30165]: "S_oc23_tunnel"[1] 83.250.111.111 #1: responding to Main Mode from unknown peer 83.250.111.111 
2013:06:13-16:22:33 oc23 pluto[30165]: "S_oc23_tunnel"[1] 83.250.111.111 #1: NAT-Traversal: Result using RFC 3947: no NAT detected 
2013:06:13-16:22:33 oc23 pluto[30165]: "S_oc23_tunnel"[1] 83.250.111.111 #1: ignoring informational payload, type IPSEC_INITIAL_CONTACT 
2013:06:13-16:22:33 oc23 pluto[30165]: "S_oc23_tunnel"[1] 83.250.111.111 #1: Peer ID is ID_USER_FQDN: 'oc23@hotmail.se' 
2013:06:13-16:22:33 oc23 pluto[30165]: "S_oc23_tunnel"[2] 83.250.111.111 #1: deleting connection "S_oc23_tunnel"[1] instance with peer 83.250.111.111 {isakmp=#0/ipsec=#0} 
2013:06:13-16:22:33 oc23 pluto[30165]: "S_oc23_tunnel"[2] 83.250.111.111 #1: Dead Peer Detection (RFC 3706) enabled 
2013:06:13-16:22:33 oc23 pluto[30165]: "S_oc23_tunnel"[2] 83.250.111.111 #1: sent MR3, ISAKMP SA established 
2013:06:13-16:22:33 oc23 pluto[30165]: "S_oc23_tunnel"[2] 83.250.111.111 #1: received Delete SA payload: deleting ISAKMP State #1 
2013:06:13-16:22:33 oc23 pluto[30165]: "S_oc23_tunnel"[2] 83.250.111.111: deleting connection "S_oc23_tunnel"[2] instance with peer 83.250.111.111 {isakmp=#0/ipsec=#0} 
2013:06:13-16:22:33 oc23 pluto[30165]: packet from 83.250.111.111:500: Informational Exchange is for an unknown (expired?) SA 
2013:06:13-16:22:33 oc23 pluto[30165]: packet from 83.250.111.111:500: Informational Exchange is for an unknown (expired?) SA

Does this still point in the same direction?

Peer ID is ID_USER_FQDN: 'oc23@hotmail.se' 

Like papa said...  That's not an FQDN.  I wonder if you haven't run afoul of what I call The Zeroeth Rule:

Start with a hostname that is an FQDN resolvable in public DNS to your public IP.
If you didn't do that, start over with a factory reset; it will save you hours and frustration.

Is that your issue?  There are workarounds, but...

Are you doing this with certificates, a PSK or RSA keys?

Cheers - Bob

Thank you,

I only work on this problem occasionally, because of many other customers needs.

Oh, that is true.. Changed that email-adress to the dyndns adress instead.

It is true that the hostname on the Astaro at first was not the dyndns name but something different. I changed that though at the same time I first tried to get this tunnel up and running. But if I understand you right, it can still be bad things left in the system because of this?

I now tried to change several things, just to get any tunnel up. I am using PSK, just to make it simple. But I don't get the tunnel up and running anyway.
I only have a dynamic IP on the zywall side, but just for testing I use that IP as if it was static for the moment.

This is from the Astaro log, when Astaro tries to initiates the connection:
2013:06:17-18:46:52 oc23 pluto[26339]: "S_oc23_gw2" #63: starting keying attempt 46 of an unlimited number
2013:06:17-18:46:52 oc23 pluto[26339]: "S_oc23_gw2" #64: initiating Main Mode to replace #63
2013:06:17-18:46:52 oc23 pluto[26339]: "S_oc23_gw2" #64: ignoring Vendor ID payload [f758f22668750f03b08df6ebe1******]
2013:06:17-18:46:52 oc23 pluto[26339]: "S_oc23_gw2" #64: ignoring Vendor ID payload [afcad71368a1f1c96b8696******]
2013:06:17-18:46:52 oc23 pluto[26339]: "S_oc23_gw2" #64: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
2013:06:17-18:46:52 oc23 pluto[26339]: "S_oc23_gw2" #64: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
2013:06:17-18:46:52 oc23 pluto[26339]: "S_oc23_gw2" #64: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
2013:06:17-18:46:52 oc23 pluto[26339]: "S_oc23_gw2" #64: received Vendor ID payload [RFC 3947]
2013:06:17-18:46:52 oc23 pluto[26339]: "S_oc23_gw2" #64: received Vendor ID payload [XAUTH]
2013:06:17-18:46:52 oc23 pluto[26339]: "S_oc23_gw2" #64: received Vendor ID payload [Dead Peer Detection]
2013:06:17-18:46:52 oc23 pluto[26339]: "S_oc23_gw2" #64: ignoring Vendor ID payload [afcad71368a1f1c96b8696******]
2013:06:17-18:46:52 oc23 pluto[26339]: "S_oc23_gw2" #64: ignoring Vendor ID payload [Cisco-Unity]
2013:06:17-18:46:52 oc23 pluto[26339]: "S_oc23_gw2" #64: enabling possible NAT-traversal with method 3
2013:06:17-18:46:52 oc23 pluto[26339]: "S_oc23_gw2" #64: NAT-Traversal: Result using RFC 3947: no NAT detected
2013:06:17-18:48:02 oc23 pluto[26339]: "S_oc23_gw2" #64: max number of retransmissions (2) reached STATE_MAIN_I3. Possible authentication failure: no acceptable response to our first encrypted message 

Log from Astaro, when the Zywall tries to initiate the connection:
2013:06:17-18:49:33 oc23 pluto[26339]: packet from 83.250.111.111:500: ignoring Vendor ID payload [f758f22668750f03b08df6ebe1******]
2013:06:17-18:49:33 oc23 pluto[26339]: packet from 83.250.111.111:500: ignoring Vendor ID payload [afcad71368a1f1c96b8696******]
2013:06:17-18:49:33 oc23 pluto[26339]: packet from 83.250.111.111:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
2013:06:17-18:49:33 oc23 pluto[26339]: packet from 83.250.111.111:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
2013:06:17-18:49:33 oc23 pluto[26339]: packet from 83.250.111.111:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
2013:06:17-18:49:33 oc23 pluto[26339]: packet from 83.250.111.111:500: received Vendor ID payload [RFC 3947]
2013:06:17-18:49:33 oc23 pluto[26339]: packet from 83.250.111.111:500: received Vendor ID payload [Dead Peer Detection]
2013:06:17-18:49:33 oc23 pluto[26339]: packet from 83.250.111.111:500: ignoring Vendor ID payload [afcad71368a1f1c96b8696******]
2013:06:17-18:49:33 oc23 pluto[26339]: "S_oc23_gw2" #67: responding to Main Mode
2013:06:17-18:49:33 oc23 pluto[26339]: "S_oc23_gw2" #67: NAT-Traversal: Result using RFC 3947: no NAT detected
2013:06:17-18:49:33 oc23 pluto[26339]: "S_oc23_gw2" #67: ignoring informational payload, type IPSEC_INITIAL_CONTACT
2013:06:17-18:49:33 oc23 pluto[26339]: "S_oc23_gw2" #67: Peer ID is ID_IPV4_ADDR: '83.250.111.111'
2013:06:17-18:49:33 oc23 pluto[26339]: "S_oc23_gw2" #67: Dead Peer Detection (RFC 3706) enabled
2013:06:17-18:49:33 oc23 pluto[26339]: "S_oc23_gw2" #67: sent MR3, ISAKMP SA established
2013:06:17-18:49:33 oc23 pluto[26339]: "S_oc23_gw2" #67: received Delete SA payload: deleting ISAKMP State #67
2013:06:17-18:49:33 oc23 pluto[26339]: packet from 83.250.111.111:500: Informational Exchange is for an unknown (expired?) SA
2013:06:17-18:49:33 oc23 pluto[26339]: packet from 83.250.111.111:500: Informational Exchange is for an unknown (expired?) SA

Best Regards
Andreas

Andreas, in the log when the UTM was initiating, are there lines from before where an ISAKMP SA was established? I guess so since Main Mode was initiated.

Possible authentication failure: no acceptable response to our first encrypted message

I'm thinking this is a VPN ID issue, a mismatched PSK or a policy conflict.

• First, try with a simple PSK.
  
• If that doesn't fix the problem, please show pictures of the Edits of the IPsec Connection, Remote Gateway and Policy.
  
• Also pictures of the corresponding configuration from the other side.
  
• Confirm that both sides have the public IP on the external interfaces of the VPN endpoints.

Cheers - Bob