IPSEC VPN ID Question

The VPN ID can't be changed if you use PSK authentication. However, it should work if you configure the ASG's VPN ID to "192.168.0.105" on the head office machine. Or you could use RSA/x509 based authentication which always gives you better security than PSK.

Hello,

Thank you for your prompt response.
I am glad to learn that I had not missed something obvious!!
(and at the same time a little disappointed [:D] ) 

I was using a Billion S10 before where I was able to set the VPN ID to 81.222.205.125 in the above scenario and it worked fine.

As I now understand it the Astaro has a limitation in that it is not possible to change the VPN ID if PSK is used?

The only was this would be possible with the Astaro is to set the HeadOffice VPN ID for this tunnel to the internal NAT address of the astaro e.g 192.168.0.105?

Is the above understanding correct?

Thanks again.

Yes, you got it right.

Hi, snooty, and welcome to the User BB!

I'm not following your question, nor the comment of d12fk.  I don't think the problem is the name your Astaro uses to identify the connection, but we should look at the IPsec log to confirm that.  My guess would have been that NAT-T is not enabled on both sides; again, the log would help.

Cheers - Bob

Hello All,

Thank you d12fk for the confirmation, and thank you BAlfson for the welcome, it certainly is more lively here than some other forums!

The basic problem is that that the S2S at headoffice is set to connect to 81.222.205.125 which is the fixed IP at the localsite.

However as the astaro at the localsite is behind a NAT router (NAT-T is selected on) and has a WAN IP of 192.168.0.105
given to it by the router the astaro presents its WAN_IP as 192.168.0.105

On the Billion S10 I get round this problem by setting the local ID to IP Address to 81.222.205.125
so that while the Billion S10 may have a WAN IP of 192.168.0.105 it presents its ID as 81.222.205.125 and a tunnel is established.

I had thought that in remote gateway setting
VPN ID type: IP Address and VPN ID (optional): 81.222.205.125 
would work but it does not seem to have no effect.

The non working Tunnel presented 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

I think the key to the solution is being able to change the above VPN ID to 81.222.205.125 

In summary if I use the Billion S10 behind the router it all works fine, if I pull it out and replace with astaro in exactly the same situation then it does not work.

From this I work out that the Headoffice side is working fine and either I have not configured the astaro properly or it is not possible with astaro!

I have attached the log extract for you to take a look at and would be grateful for any insight if there is anything I have missed.

Thanks
Peter

I'll try to elaborate then.

When using PSK the ASG automatically uses the IP address of the interface the connection is configured for as VPN ID. Snooty has a router in front of the ASG on one side, which does DNAT for UDP/500 and UDP/4500, forwarding incoming IKE traffic towards the ASG. So, the ASG appears to it's remote peer being reachable at the forwarding routers public IP address 81.222.205.125. The VPN ID it uses is the internal IP address 192.168.0.105, though.

The question was where to configure the VPN ID to be 81.222.205.125.
The answer was: you can't. That made snooty a sad panda... and me sorry. =)

I have attached the log extract for you to take a look at and would be grateful for any insight if there is anything I have missed.

The key line here is "ignoring informational payload, type INVALID_ID_INFORMATION". So, the peer is somehow dissatisfied with the ID you sent it. It expects it to be the external IP. So, you want to change the configuration on that router to expect the VPN ID that is actually sent, the internal IP address. As I said before, there's no way to configure the local VPN ID for PSK on the ASG.

Hi d12fk

>>That made snooty a sad panda...
That put a smile on my face, thank you [:)]

Thanks for the explanation, it has saved me further headscratching trying to work out what I was doing wrong.

Just as a point of information for anybody else facing the same problem....

The only way around this issue that I have discovered is set the headoffice as respond only rather than initiate contact.
This way the headoffice site does not need to know the branchend ip address.
This would also be useful not only in my situation but also where the branchend has a dynamic IP.
I have tested this and it works, however it is obviously less secure as the branchend is no longer restricted to a specific ip address.
(although now I am not sure how much security that really affords given that devices such as the Billion can set their VPN ID).

I will take your suggestion and look into RSA/x509 based authentication in the future but thought it would be better to start
with what I already know!

Once again thanks for all you help.

Peter

From the log file I've seen that there is strongSwan running on the other site as well. Is it an ASG? If so, you could specify the remote gateway VPN ID IP address easily. Or can't you because you have no access to that machine?

Hi,

Yes it is an ASG on the other side, I am running things in test mode at the momement.

We normally run Cisco ASA units (5505 at each Branch End and 5520 at HeadEnd)
and I am testing to see if Astaro is a better fit for our needs.
The lack of simple White list URL filtering on the 5505 units among other things is a major pain in the ***.

By specify the remote gateway VPN ID IP address easily - you mean set the gateway host IP as 192.168.0.105?

If so then yes you are correct in that at the HeadEnd I could specify the VPN ID for the branch end as 192.168.0.105 on the headend side. (Especially now that I know this is the problem!)

But I am partly trying to develop a 'neat' solution so that it can be scaled up without issue and partly learn at the same time [:D]

While not a network expert, in the few lessons that I had I was always taught to always restrict the ID to fixed IP addresses to increase security. 
Of course this may be totally wrong [:$]


Thanks
Peter