Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 1 subscriber
  • Views 2255 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IPSec VPN ASG8 <-> Bintec Router: "no connection has been authorized"

a.e
Hi I'm desperately trying to set a a Site-to-Site-VPN connection between an astaro sg8 and some bintec router located in a branch office (i have no access to). I figured this should be straight forward because we are using PSK and have static public ip addresses on each side. No NAT is involved.

So far I managed to negotiate the necessary connection paramaters with my colleague by phone. The problem is, that the connection doesn't get established. Here is the relevant log output: 


2011:05:25-21:30:12 bravo pluto[7033]: packet from a.a.a.a:671: ignoring Vendor ID payload [0048e2270bea8395ed778d343cc2a076]

2011:05:25-21:30:12 bravo pluto[7033]: packet from a.a.a.a:671: ignoring Vendor ID payload [5cbeb399eb835a7d7a2eb495905db061]

2011:05:25-21:30:12 bravo pluto[7033]: packet from a.a.a.a:671: ignoring Vendor ID payload [810fa565f8ab14369105d706fbd57279]

2011:05:25-21:30:12 bravo pluto[7033]: packet from a.a.a.a:671: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]

2011:05:25-21:30:12 bravo pluto[7033]: packet from a.a.a.a:671: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]

2011:05:25-21:30:12 bravo pluto[7033]: packet from a.a.a.a:671: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]

2011:05:25-21:30:12 bravo pluto[7033]: packet from a.a.a.a:671: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]

2011:05:25-21:30:12 bravo pluto[7033]: packet from a.a.a.a:671: received Vendor ID payload [XAUTH]

2011:05:25-21:30:12 bravo pluto[7033]: packet from a.a.a.a:671: received Vendor ID payload [Dead Peer Detection]

2011:05:25-21:30:12 bravo pluto[7033]: | ****parse IPsec DOI SIT:

2011:05:25-21:30:12 bravo pluto[7033]: | IPsec DOI SIT: SIT_IDENTITY_ONLY

2011:05:25-21:30:12 bravo pluto[7033]: | ****parse ISAKMP Proposal Payload:

2011:05:25-21:30:12 bravo pluto[7033]: | next payload type: ISAKMP_NEXT_NONE

2011:05:25-21:30:12 bravo pluto[7033]: | length: 40

2011:05:25-21:30:12 bravo pluto[7033]: | proposal number: 0

2011:05:25-21:30:12 bravo pluto[7033]: | protocol ID: PROTO_ISAKMP

2011:05:25-21:30:12 bravo pluto[7033]: | SPI size: 0

2011:05:25-21:30:12 bravo pluto[7033]: | number of transforms: 1

2011:05:25-21:30:12 bravo pluto[7033]: | *****parse ISAKMP Transform Payload (ISAKMP):

2011:05:25-21:30:12 bravo pluto[7033]: | next payload type: ISAKMP_NEXT_NONE

2011:05:25-21:30:12 bravo pluto[7033]: | length: 32

2011:05:25-21:30:12 bravo pluto[7033]: | transform number: 0

2011:05:25-21:30:12 bravo pluto[7033]: | transform ID: KEY_IKE

2011:05:25-21:30:12 bravo pluto[7033]: | ******parse ISAKMP Oakley attribute:

2011:05:25-21:30:12 bravo pluto[7033]: | af+type: OAKLEY_ENCRYPTION_ALGORITHM

2011:05:25-21:30:12 bravo pluto[7033]: | length/value: 5

2011:05:25-21:30:12 bravo pluto[7033]: | ******parse ISAKMP Oakley attribute:

2011:05:25-21:30:12 bravo pluto[7033]: | af+type: OAKLEY_HASH_ALGORITHM

2011:05:25-21:30:12 bravo pluto[7033]: | length/value: 2

2011:05:25-21:30:12 bravo pluto[7033]: | ******parse ISAKMP Oakley attribute:

2011:05:25-21:30:12 bravo pluto[7033]: | af+type: OAKLEY_AUTHENTICATION_METHOD

2011:05:25-21:30:12 bravo pluto[7033]: | length/value: 1

2011:05:25-21:30:12 bravo pluto[7033]: | ******parse ISAKMP Oakley attribute:

2011:05:25-21:30:12 bravo pluto[7033]: | af+type: OAKLEY_GROUP_DESCRIPTION

2011:05:25-21:30:12 bravo pluto[7033]: | length/value: 2

2011:05:25-21:30:12 bravo pluto[7033]: | ******parse ISAKMP Oakley attribute:

2011:05:25-21:30:12 bravo pluto[7033]: | af+type: OAKLEY_LIFE_TYPE

2011:05:25-21:30:12 bravo pluto[7033]: | length/value: 1

2011:05:25-21:30:12 bravo pluto[7033]: | ******parse ISAKMP Oakley attribute:

2011:05:25-21:30:12 bravo pluto[7033]: | af+type: OAKLEY_LIFE_DURATION

2011:05:25-21:30:12 bravo pluto[7033]: | length/value: 28800

2011:05:25-21:30:12 bravo pluto[7033]: | preparse_isakmp_policy: peer requests PSK authentication

2011:05:25-21:30:12 bravo pluto[7033]: packet from a.a.a.a:671: initial Main Mode message received on b.b.b.b:500 but no connection has been authorized with policy=PSK

2011:05:25-21:30:12 bravo pluto[7033]: | next event EVENT_RETRANSMIT in 0 seconds for #3

2011:05:25-21:30:12 bravo pluto[7033]: |

2011:05:25-21:30:12 bravo pluto[7033]: | *time to handle event

2011:05:25-21:30:12 bravo pluto[7033]: | event after this is EVENT_REINIT_SECRET in 2010 seconds

2011:05:25-21:30:12 bravo pluto[7033]: | handling event EVENT_RETRANSMIT for a.a.a.a "S_VPN_WUG_MUC_PHONES" #3

2011:05:25-21:30:12 bravo pluto[7033]: | inserting event EVENT_RETRANSMIT, timeout in 20 seconds for #3

2011:05:25-21:30:12 bravo pluto[7033]: | next event EVENT_RETRANSMIT in 20 seconds for #3


the error seems to be this: 


2011:05:25-21:30:12 bravo pluto[7033]: packet from a.a.a.a:671: initial Main Mode message received on b.b.b.b:500 but no connection has been authorized with policy=PSK


There are no (relevant) entries in the packet filter log and there is no difference whether I enable or disable NAT-T.

I redid the same configuration over and over on the astaro side to be sure thera are no typos and all ips are correct. I don't know what could cause this. Does anyone have any good advice?


This thread was automatically locked due to age.
Parents
  • 0
    just for informational sake... the actual problem preventing the tunnel from going up was a missing route. the astaro side had many dedicated internet connections and without a clear route it appeared that answers to connection attempts would be sent over a different interface/ip.
Reply
  • 0
    just for informational sake... the actual problem preventing the tunnel from going up was a missing route. the astaro side had many dedicated internet connections and without a clear route it appeared that answers to connection attempts would be sent over a different interface/ip.
Children
No Data