Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 1 subscriber
  • Views 4959 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 site-to-site across NAT

Hipshot
Hi Guys
I'm in a pickle and need help.
We're moving offices tomorrow, and only today I learned that the ISP delivers NAT'ed Internet connectivity on the now location.

Abbreviations:
AGS-DC   =  Astaro at my Datacenter. Has public IP on its external i/f
AGS-OFC =  Astaro in the new office. Has a 10.7.x.y address on external.
ISP-GW = Public address of ISP's NAT router.

Situation:
AGS-DC ---Internet--ISP-GW---10.7.x.0/24 - AGS-OFC

In AGS-DC I have added a "Host" definition for the Office AGS. The IP adress is the Public ISP-GW address.

Then, set up a remote key at both end, (psk) and of we go. Not...

The log at the AGS-DC shows:

"S_CW-VPN-WTC-Schiphol_0" #11673: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
"S_CW-VPN-WTC-Schiphol_0" #11673: STATE_MAIN_R1: sent MR1, expecting MI2
"S_CW-VPN-WTC-Schiphol_0" #11673: NAT-Traversal: Result using 3: peer is NATed
"S_CW-VPN-WTC-Schiphol_0" #11673: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
"S_CW-VPN-WTC-Schiphol_0" #11673: STATE_MAIN_R2: sent MR2, expecting MI3
"S_CW-VPN-WTC-Schiphol_0" #11673: Main mode peer ID is ID_IPV4_ADDR: '10.7.184.2'
"S_CW-VPN-WTC-Schiphol_0" #11673: no suitable connection for peer '10.7.184.2'
"S_CW-VPN-WTC-Schiphol_0" #11673: sending encrypted notification INVALID_ID_INFORMATION to 194.151.91.70:4500
"S_CW-VPN-WTC-Schiphol_0" #11673: Main mode peer ID is ID_IPV4_ADDR: '10.7.184.2'
"S_CW-VPN-WTC-Schiphol_0" #11673: no suitable connection for peer '10.7.184.2'
"S_CW-VPN-WTC-Schiphol_0" #11673: sending encrypted notification INVALID_ID_INFORMATION to 194.151.91.70:4500
"S_CW-VPN-WTC-Schiphol_0" #11673: Main mode peer ID is ID_IPV4_ADDR: '10.7.184.2'
"S_CW-VPN-WTC-Schiphol_0" #11673: no suitable connection for peer '10.7.184.2'
"S_CW-VPN-WTC-Schiphol_0" #11673: sending encrypted notification INVALID_ID_INFORMATION to 194.151.91.70:4500

So the AGS-DC is confused. It expects to talk to 194.151.92.70, but gets answer by 10.7.184.12 instead !

Obviously, I can't define the "10" network as remote gatweay, because that will get me a "no route to host" type of error.

So how do I get out of this situation. Is there a walk-through of how to approach this? I need to get this live by tomorrow COB... 

Thanks 
Hip


This thread was automatically locked due to age.
  • 0
    This sucks and it's one of the reasons why people need to be aware of what exactly their ISP is providing before they try to work with them. 

    What did you end up doing?
  • 0 in reply to jjohnston62
    Hi

    we do have exactly the same problem in a customers network.
    I thought you could work around with the optional VPN ID but Astaro V7 allways takes the local address instead of the IP we entered?
    Did you find a solution for it?

    -Matthias
  • 0 in reply to MatthiasD
    This thread is old, but it might help for some...

    It looks to me as you should use the RSA Public keys or x509.
    I noticed that when you use shared pass-phrase on v7, you are limited to IP for the VPN ID, not so with RSA or X509.

    Pierre
  • 0
    Hip,

    You must have a public IP address on each of the Gateways for an IPSEC tunnel to work reliably. Beat up the ISP and see if they will issue you a fixed public IP Address.  

    I have several IPSEC tunnels in use and they are normally just fine, provided they are set up correctly, but the settings must match on both sides of the cloud.

    Dave P
  • 0 in reply to dpritt
    Hi there, 
    just to be precise, 
    It is not required to have public ip adresses on each end.

    You must use RSA or X509 authentication and you must supply a VPN-ID different than the ip adress, i would suggest you use the hostname. (this hostname most not be resolvable, it is just a name tag).

    Than configure the gateway type of the device with the public ip as "Respond only" and the other locations as 'Initiate connection".

    This will lead to that the branches always connect the HQ and averything is fine.
    You should enable Dead Peer Detection (in the Advanced tab) so that each side immidieatly detects if a side has disconnected and reinnitiates the connection.

    hope that helps, 
    regards
    Gert
Cookie Information Banner