Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 1 subscriber
  • Views 52271 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 ID Question

snooty
Hello,

I am stuck on a issue which is probably very simple but cannot work it out [:S]  Any help would be appreciated.

I am trying to set up a IPSEC Site2Site Tunnel allong the following setup:

(LocalNet:192.168.210.0/24)--(LocalAstaro WAN:192.168.0.105)--(LocalRouterWAN:81.222.205.125)
===Internet===
(HeadOfficeWAN:85.196.155.70)--(HeadOfficeNet:192.168.150.0/25)

So the local astaro is stuck behind a router which gives it the IP:192.168.0.105

Now I know that the solution to this is to enable NAT (Done)
and set the VPN ID at the local side to 81.222.205.125 and it should work.
As the Headoffice VPN is set to communicate to 81.222.205.125

The question is how to set the local VPN ID to 81.222.205.125???

I had thought this would be set in Remote Gateway -- VPN ID Type: IP Address -- VPN ID 81.222.205.125
but this seems to have no effect?

The tunnel that is displayed is:
SA: 192.168.210.0/24=192.168.0.105   85.196.155.70=192.168.150.0/24
VPN ID: 192.168.0.105
Error: No connection

Clearly the tunnel will not work until I am able to set the VPN ID: 81.222.205.125
but how????????? [:O]

Thanks


This thread was automatically locked due to age.
Parents
  • 0
    Thank you guys for the explanations, they were very helpful in saving me from pulling my hair out!

    A couple of notes that I found as a result of my trials which I thought would be good to share.

    * Regardless of whatever is set in the VPN ID at the BranchEnd, the HeadEnd will always only respond to the static ip set at the 
    headend.
    This means that while the VPN ID is required to be set with WAN IP (needed if the devices is behind a router), the headend will only respond to the static IP set. This would seem to be an improvement in security.

    *However d12fk is correct in that this security is very poor for the following reason.
    If the branchend is behind a router then you would appear to have no choice but to set the VPN ID to the same as the WANIP
    (otherwise the tunnel will not work) which (as d12fk states) makes it easier for an attacker to hack.
    I will need to rethink my security model [:O]

    *From what I can see the Billion devices (used as low cost devices at the Branch End) for IPSEC do not allow anything other than preshared keys. It is therefore not possible to use RSA or X509 without upgrades at branch end.
    I think I will have to do some research into low cost vpn devices for the branch end.

    Thanks again for all your help
    Peter
Reply
  • 0
    Thank you guys for the explanations, they were very helpful in saving me from pulling my hair out!

    A couple of notes that I found as a result of my trials which I thought would be good to share.

    * Regardless of whatever is set in the VPN ID at the BranchEnd, the HeadEnd will always only respond to the static ip set at the 
    headend.
    This means that while the VPN ID is required to be set with WAN IP (needed if the devices is behind a router), the headend will only respond to the static IP set. This would seem to be an improvement in security.

    *However d12fk is correct in that this security is very poor for the following reason.
    If the branchend is behind a router then you would appear to have no choice but to set the VPN ID to the same as the WANIP
    (otherwise the tunnel will not work) which (as d12fk states) makes it easier for an attacker to hack.
    I will need to rethink my security model [:O]

    *From what I can see the Billion devices (used as low cost devices at the Branch End) for IPSEC do not allow anything other than preshared keys. It is therefore not possible to use RSA or X509 without upgrades at branch end.
    I think I will have to do some research into low cost vpn devices for the branch end.

    Thanks again for all your help
    Peter
Children
No Data