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.
  • 0
    I finally got this log message to disappear. As one can see the packets of the peer originate from port 671. For some reason FreeS/WAN does not like this. On top of the ip addresses matching, the source and destination ports have to be no others then 500. 

    So I'm one step further but for some unknown reason the vpn connection still isn't coming up. Is there any way to deeper inspect the connection attempts besides the live log? This is what scrolls through: 


    2011:05:30-16:17:53 bravo pluto[14194]: | next event EVENT_REINIT_SECRET in 710 seconds

    2011:05:30-16:24:19 bravo pluto[14194]: |

    2011:05:30-16:24:19 bravo pluto[14194]: | *received whack message

    2011:05:30-16:24:19 bravo pluto[14194]: | next event EVENT_REINIT_SECRET in 324 seconds

    2011:05:30-16:29:43 bravo pluto[14194]: |

    2011:05:30-16:29:43 bravo pluto[14194]: | *time to handle event

    2011:05:30-16:29:43 bravo pluto[14194]: | event after this is EVENT_LOG_DAILY in 27017 seconds

    2011:05:30-16:29:43 bravo pluto[14194]: | event EVENT_REINIT_SECRET handled

    2011:05:30-16:29:43 bravo pluto[14194]: | inserting event EVENT_REINIT_SECRET, timeout in 3600 seconds

    2011:05:30-16:29:43 bravo pluto[14194]: | next event EVENT_REINIT_SECRET in 3600 seconds
  • 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.