Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 1 subscriber
  • Views 8166 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

Site 2 Site VPN fails when target has multiple interfaces

mrainey
SG 310 V 9-312-8
I have VPN's connected to a group of mobile cradlepoint routers with aircards for Internet access. All is good. HOWEVER; because of the terrain where they travel, they are now being outfitted with 2 aircards, 1 each from 2 different vendors. Seemed pretty simple, I should be able to just create an availability group on the Sophos and use that in the gateway. Sadly, doesn't work. I get "no connection has been authorized for policy=PSK" I tried setting UTM to respond only, but get Invalid ID. Any hope?


This thread was automatically locked due to age.
Parents
  • 0
    I'm not familiar with those routers, and I don't understand if both aircards are connected at the same time.  If they're both connected in one of the routers, you will need something in it like 'Interface Groups' or 'Uplink Balancing' with 'Multipath Balancing'.  In the UTM, you should then be able to use an Availability Group (with order corresponding to the preference in the router) for each router or to make the Remote Gateways "Respond Only."

    If the routers only have one aircard active at a time, then either of the above solutions for the UTM should work just fine.

    Any luck with any of that?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    Only one card is active at a time, so yes it seemed like a simple availability group should work, however; I get the error messages above when I try that. The only significant change on the Cradlepoint I make is that I have to blank out the local identity field instead of specifying an IP address. In that case, it is supposed to default to the External WAN Internet address, i.e.; the active card. When I tried the Respond Only I get the Invalid ID error.
  • 0 in reply to mrainey
    38005 is the unit in question:
    2015:07:10-12:46:39 aceutm pluto[6231]: packet from 24.221.75.168:500: received Vendor ID payload [RFC 3947]
    2015:07:10-12:46:39 aceutm pluto[6231]: packet from 24.221.75.168:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
    2015:07:10-12:46:39 aceutm pluto[6231]: packet from 24.221.75.168:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
    2015:07:10-12:46:39 aceutm pluto[6231]: packet from 24.221.75.168:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
    2015:07:10-12:46:39 aceutm pluto[6231]: packet from 24.221.75.168:500: received Vendor ID payload [Dead Peer Detection]
    2015:07:10-12:46:39 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[1] 24.221.75.168 #85063: responding to Main Mode from unknown peer 24.221.75.168
    2015:07:10-12:46:40 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[1] 24.221.75.168 #85063: NAT-Traversal: Result using RFC 3947: no NAT detected
    2015:07:10-12:46:40 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[1] 24.221.75.168 #85063: Peer ID is ID_IPV4_ADDR: '24.221.75.168'
    2015:07:10-12:46:40 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[1] 24.221.75.168 #85063: Dead Peer Detection (RFC 3706) enabled
    2015:07:10-12:46:40 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[1] 24.221.75.168 #85063: sent MR3, ISAKMP SA established
    2015:07:10-12:46:40 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[1] 24.221.75.168 #85063: ignoring informational payload, type IPSEC_INITIAL_CONTACT
    2015:07:10-12:46:41 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[1] 24.221.75.168 #85063: cannot respond to IPsec SA request because no connection is known for 192.168.114.0/24===63.227.59.35[63.227.59.35]:6/0...24.221.75.168[24.221.75.168]:6/0===192.168.5.0/24
    2015:07:10-12:46:41 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[1] 24.221.75.168 #85063: sending encrypted notification INVALID_ID_INFORMATION to 24.221.75.168:500
    2015:07:10-12:46:42 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[1] 24.221.75.168 #85063: cannot respond to IPsec SA request because no connection is known for 192.168.114.0/24===63.227.59.35[63.227.59.35]:6/0...24.221.75.168[24.221.75.168]:6/0===192.168.5.0/24
    2015:07:10-12:46:42 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[1] 24.221.75.168 #85063: sending encrypted notification INVALID_ID_INFORMATION to 24.221.75.168:500
    2015:07:10-12:46:43 aceutm pluto[6231]: "S_CDoT 38001 1100-55a" #84955: ignoring informational payload, type NO_PROPOSAL_CHOSEN
    2015:07:10-12:46:51 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[1] 24.221.75.168 #85063: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x3d5df69a (perhaps this is a duplicated packet)
    2015:07:10-12:46:51 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[1] 24.221.75.168 #85063: sending encrypted notification INVALID_MESSAGE_ID to 24.221.75.168:500
    2015:07:10-12:46:52 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[1] 24.221.75.168 #85063: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0xca3f56fe (perhaps this is a duplicated packet)
    2015:07:10-12:46:52 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[1] 24.221.75.168 #85063: sending encrypted notification INVALID_MESSAGE_ID to 24.221.75.168:500
    2015:07:10-12:46:54 aceutm pluto[6231]: "S_CDoT 38003 1100-55d" #85059: max number of retransmissions (2) reached STATE_QUICK_I1
    2015:07:10-12:46:54 aceutm pluto[6231]: "S_CDoT 38003 1100-55d" #85059: starting keying attempt 91 of an unlimited number
    2015:07:10-12:46:54 aceutm pluto[6231]: "S_CDoT 38003 1100-55d" #85064: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP to replace #85059 {using isakmp#84593}
    2015:07:10-12:46:55 aceutm pluto[6231]: "S_CDoT 38003 1100-55d" #84593: ignoring informational payload, type NO_PROPOSAL_CHOSEN
    2015:07:10-12:47:01 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[1] 24.221.75.168 #85063: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x3d5df69a (perhaps this is a duplicated packet)
    2015:07:10-12:47:01 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[1] 24.221.75.168 #85063: sending encrypted notification INVALID_MESSAGE_ID to 24.221.75.168:500
    2015:07:10-12:47:02 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[1] 24.221.75.168 #85063: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0xca3f56fe (perhaps this is a duplicated packet)
    2015:07:10-12:47:02 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[1] 24.221.75.168 #85063: sending encrypted notification INVALID_MESSAGE_ID to 24.221.75.168:500
  • 0 in reply to mrainey
    So not sure what worked, I had tried changing the protocol tab on the Cradlepoint from Any to UDP, didn't change anything so I switched it back to Any. Bounced the config on the router and the tunnel came up. Here is the live log now: If all else fails, reboot it.

    Now, I just need to get the aircard flipped to the 2nd vendor and see if it comes back up. The Respond Only with Availability Group would certainly make life easier with these 15 mobile units.

    "S_CDoT 38005 1100-560"[6] 24.221.75.168 #85413: responding to Main Mode from unknown peer 24.221.75.168
    2015:07:10-14:39:38 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[6] 24.221.75.168 #85413: NAT-Traversal: Result using RFC 3947: no NAT detected
    2015:07:10-14:39:39 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[6] 24.221.75.168 #85413: Peer ID is ID_IPV4_ADDR: '24.221.75.168'
    2015:07:10-14:39:39 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[6] 24.221.75.168 #85413: Dead Peer Detection (RFC 3706) enabled
    2015:07:10-14:39:39 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[6] 24.221.75.168 #85413: sent MR3, ISAKMP SA established
    2015:07:10-14:39:39 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[6] 24.221.75.168 #85413: ignoring informational payload, type IPSEC_INITIAL_CONTACT
    2015:07:10-14:39:40 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[6] 24.221.75.168 #85414: responding to Quick Mode
    2015:07:10-14:39:40 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[6] 24.221.75.168 #85414: IPsec SA established {ESP=>0x0c4e486d 
Reply
  • 0 in reply to mrainey
    So not sure what worked, I had tried changing the protocol tab on the Cradlepoint from Any to UDP, didn't change anything so I switched it back to Any. Bounced the config on the router and the tunnel came up. Here is the live log now: If all else fails, reboot it.

    Now, I just need to get the aircard flipped to the 2nd vendor and see if it comes back up. The Respond Only with Availability Group would certainly make life easier with these 15 mobile units.

    "S_CDoT 38005 1100-560"[6] 24.221.75.168 #85413: responding to Main Mode from unknown peer 24.221.75.168
    2015:07:10-14:39:38 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[6] 24.221.75.168 #85413: NAT-Traversal: Result using RFC 3947: no NAT detected
    2015:07:10-14:39:39 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[6] 24.221.75.168 #85413: Peer ID is ID_IPV4_ADDR: '24.221.75.168'
    2015:07:10-14:39:39 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[6] 24.221.75.168 #85413: Dead Peer Detection (RFC 3706) enabled
    2015:07:10-14:39:39 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[6] 24.221.75.168 #85413: sent MR3, ISAKMP SA established
    2015:07:10-14:39:39 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[6] 24.221.75.168 #85413: ignoring informational payload, type IPSEC_INITIAL_CONTACT
    2015:07:10-14:39:40 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[6] 24.221.75.168 #85414: responding to Quick Mode
    2015:07:10-14:39:40 aceutm pluto[6231]: "S_CDoT 38005 1100-560"[6] 24.221.75.168 #85414: IPsec SA established {ESP=>0x0c4e486d 
Children
No Data
Unfiltered HTML