IPSEC ASG220 -> Symantec 320

Hi, klindsay, and welcome to the User BB!

Please [Go Advanced] below and attach a picture of the 'Site-to-site VPN tunnel status'.  Also, post the first 100 log lines from the following:

- Disable the IPsec Connection
- Start the IPsec Live Log
- Enable the IPsec connection, and leave it on until it's clear you have enough

Cheers - Bob

Thanks for the help Bob,

I've attached the screen capture and the log.

That all looks good.  I think you can turn off the IKE debugging since the IPsec SA gets established.

Here are the three lines that make me think there's a disagreement about the PSK:

2012:05:03-15:47:35 gate1 pluto[7166]: "S_Brantford" #272: Can't authenticate: no preshared key found for '64.x.y.131' and '64.x.y.132'. Attribute OAKLEY_AUTHENTICATION_METHOD

2012:05:03-15:47:35 gate1 pluto[7166]: "S_Brantford" #272: no acceptable Oakley Transform

2012:05:03-15:47:35 gate1 pluto[7166]: "S_Brantford" #272: sending notification NO_PROPOSAL_CHOSEN to 64.x.y.132:500

Does this work if you try a simple PSK like 123abc?

If that doesn't do it, then, I'd suspect something in between that isn't letting protocol 50 &/or 51 get through.

Cheers - Bob
PS RSA keys are almost as secure as certificates and just as easy to configure as PSKs if the Symantec can do that.

Hi Bob,

I can't try abc123 due to the fact that the Symantec requires a minimum 20 char long key.

After trying every possible combination of policy values (that exist in both the ASG and the Symantec) I did find a different error.  Please see log entries below:

2012:05:07-09:16:41 gate1 pluto[786]: "S_Brantford" #52: starting keying attempt 2 of an unlimited number
2012:05:07-09:16:41 gate1 pluto[786]: "S_Brantford" #53: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP to replace #52 {using isakmp#47}
2012:05:07-09:16:41 gate1 pluto[786]: packet from 64.140.115.132:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN
2012:05:07-09:16:41 gate1 pluto[786]: "S_Brantford" #54: responding to Main Mode
2012:05:07-09:16:41 gate1 pluto[786]: "S_Brantford" #54: Peer ID is ID_IPV4_ADDR: '64.140.115.132'
2012:05:07-09:16:41 gate1 pluto[786]: "S_Brantford" #54: sent MR3, ISAKMP SA established
2012:05:07-09:16:41 gate1 pluto[786]: "S_Brantford" #54: ignoring informational payload, type IPSEC_INITIAL_CONTACT
2012:05:07-09:16:42 gate1 pluto[786]: "S_Brantford" #55: responding to Quick Mode
 
2012:05:07-09:16:42 gate1 pluto[786]: "S_Brantford" #55: ERROR: netlink XFRM_MSG_NEWPOLICY response for flow tun.10000@64.140.115.131 included errno 17: File exists
 
2012:05:07-09:16:42 gate1 pluto[786]: "S_Brantford" #55: IPsec SA established {ESP=>0x83c2ee58 

After trying every possible combination of policy values (that exist in both the ASG and the Symantec)

There's a good chance that you will need to make a custom policy in either the Symantec or the Astaro.  Better to choose an AES-based policy as it is faster than 3DES and more-secure.  If you aren't doing top-secret stuff, AES 128 is probably adequate.  Can you duplicate the settings in the Symantec?

Again, if the Symantec has Private & Public RSA keys, you're better off to exchange public keys.

Cheers - Bob

Hi Bob, 

I had already created custom policies in both the ASG and the Symantec.

The Symantec 320, unfortunately, does not have RSA as a VPN connection option.

I have deleted the remote gateway and connection in the ASG and recreated everything. Still no Symantec -> ASG Internal traffic but ASG -> Symantec works perfectly.

Bob, it feels like we're barking up the wrong tree here with the VPN parameters.  It feels more like a routing issue where the traffic is not being allowed onto the internal network from my Symantec.  I just seems weird to me that a tunnel would be created but a parameter "mismatch" would not allow 2 way traffic.  Wouldn't a tunnel either work completely or not work?  Half working seems odd as a tunnel creation issue.

True, but it still could happen under special circumstances. However, the log you posted says:

2012:05:03-15:47:45 gate1 pluto[7166]: "S_Brantford" #273: sent QI2, IPsec SA established {ESP=>0xca7b3613  ASG case, what are you doing to test? Ping from 10.1.15.0/24 to 10.1.1.0/24? Do you see incoming and outgoing ESP packets on the ASG?

Still no Symantec -> ASG Internal traffic but ASG -> Symantec works perfectly.
 
Bob, it feels like we're barking up the wrong tree here with the VPN parameters. It feels more like a routing issue

Is it possible the the local network 10.1.15.0/24 behind the Symantec also is a network defined on the Astaro?  You could check the 'Routes Table' tab in 'Support >> Advanced'.

Also, please confirm that none of the definitions in the Astaro is bound to an interface - all should have 'Interface: >'.

Cheers - Bob
PS Heiko, if my last guess was the problem, I hope you'll urge the team to enhance the warning on the use of binding.

Thanks so much for your help guys.   My tunnel is working perfectly, as it turns out, it was all along.  My main server that i was trying to ping (every time) was configured incorrectly (wrong gateway address) and it just hadn't bit me until now.  Local networking worked perfectly fine but the Astaro didn't like not being the gateway for that server when trying to route traffic to it.

Sorry for the wild goose chase, but thanks again for all your help.