Site-to-Site IPSec VPN between Astaro and Openswan (routing, parameters)

I could have helped if I signed on to see this. But I have to re-iterate NAT and VPN are TOTALLY FINE AND GOOD.

Hi coewar and thanks for replying.

The problem is Astaro's GUI does not expose the complete  StrongSWAN configuration that it uses. Only a couple of the configurations would be needed to expose and you would not have any issues. You can do this via hacking the config files, but that is not supported.

 
I know, but I read the configuration under /var/chroot-ipsec/etc and found everything okay for my setup. In my case it was a broken linux package which offered SHA2 but did not implemented it properly. As a result I got the IPSec up and running without errors on both sides, and I saw encrypted traffic. Without SHA2 build in on one side, there simple couldn't talk to each other.

Fun fact: Even with debugging set to all on openswan - crypto debug is then also turned on - I did not see one helping output line in the log. Something like: "...hey they send some encryption we could not verify ..." :|

Check out thread about Astaro VPN with NAT.

http://www.astaro.org/astaro-gateway-products/vpn-site-site-remote-access/40679-issues-ipsec-site-site-asg-behind-front-nat.html

Yes I read that. I still have DPD and NAT issue I could not solve properly. But it seems that DPD is working and from time to time (more 30-40% at all) it simply doesn't reload the the IPSec Stack with the new IPs after declaring the peer as dead (on linux/openswan). The reason is nearly everytime a changed dynamic IP on one or both sides, not the SA itself. 

My astaro was set up as "respond only" so I couldn't blame it. The solution was writing a simple script that runs checks on the DNS-entries and restarts the service if needed. Uncool like hell - but working.

Regards Björn

My astaro was set up as "respond only" so I couldn't blame it. The solution was writing a simple script that runs checks on the DNS-entries and restarts the service if needed. Uncool like hell - but working.

Regards Björn

Could you share such a script? I have all my VPN remote gateways configured to Initiate connection mode, and I can't believe it but I have a few tunnels now that might go down and the all I do is disable and re-enable them to bring them up!???  What the heck is the DPD for? It's not working. So I have to hack something in so that it ACTUALLY restarts when it detects that it's down. Gosh I hope v9 fixes that and soon. It is silly.

I have a few tunnels now that might go down and the all I do is disable and re-enable them to bring them up!

You might want to start a thread to get some help with that.  It might be an interface issue or configuration on the other end.

Cheers - Bob

Fun fact: Even with debugging set to all on openswan - crypto debug is then also turned on - I did not see one helping output line in the log. Something like: "...hey they send some encryption we could not verify ..." :|

It could be that Openswan is not to blame here as use of SHA2 in IKE is no problem. At least I know of none. The problem normally occurs in the kernel during ESP processing when it comes to truncating the SHA2 hashsum. The IPsec SHA2 RFC draft was not explicit about truncation length, so vendors used 96 bit which was defined for MD5 and SHA1. With SHA2 96 bit truncation doesn't make much sense especially if you take SHA2-512 for example, so the final RFC defined half the output lengths as truncation. This causes incompatibilities and since ASG adheres to the RFC it's why 8.200 (IIRC) introduced special SHA2 modes for IPsec SAs with 96 bit truncation. Since the truncation length is not negotiated in IKE there's no way to detect breakage. You just have to configure it correctly with respect to the remote gateway.

My astaro was set up as "respond only" so I couldn't blame it. The solution was writing a simple script that runs checks on the DNS-entries and restarts the service if needed. Uncool like hell - but working.

Is DPD active on the affected connections? Did you run into the infamous "cannot route" error? 8.301 is for you if answered yes to both questions.

Hello d12fk,
thanks for answering.

It could be that Openswan is not to blame here as use of SHA2 in IKE is no problem.

Yes that make sense, I didn't thought of IKE.

At least I know of none. The problem normally occurs in the kernel during ESP processing when it comes to truncating the SHA2 hashsum. The IPsec SHA2 RFC draft was not explicit about truncation length, so vendors used 96 bit which was defined for MD5 and SHA1. With SHA2 96 bit truncation doesn't make much sense especially if you take SHA2-512 for example, so the final RFC defined half the output lengths as truncation. This causes incompatibilities and since ASG adheres to the RFC it's why 8.200 (IIRC) introduced special SHA2 modes for IPsec SAs with 96 bit truncation. Since the truncation length is not negotiated in IKE there's no way to detect breakage. You just have to configure it correctly with respect to the remote gateway.

Okay good to know, and make sense. Now I use SHA1 (160bit, but I'm not sure about that) and it's running fine. But anyway very usefull info especially if I want to setup a VPN between different ASG Versions or third party software like openswan. But regardless of the explanation - (fo me) it's broken openswan (you can add here: standard kernel from distribution, package from vendors repository), because ESP won't work with SHA2 as Hash. And there is no good way to debug it, only knowledge of course [[:)]]

Is there a way to implement a debug output or some comment in the configs, maybe a hint in the online help [;)] to avoid such errors? The problem with GUI tools is the lack of knowledge about important details under the hood. Or another good idea: there could be a entry in the wiki, "how to connect openswan/strongswan to an astaro gateway" 

Is DPD active on the affected connections? Did you run into the infamous "cannot route" error? 8.301 is for you if answered yes to both questions.

DPD is active on all endpoints, I still run v8.301 and I don't see this this message on openswan or astaro side [[:)]] 

Example: left - astaro - side got a new IP

Astaro ipsec.log
[FONT="Courier New"]#5: DPD: Restarting all connections of peer
#5: DPD: Terminating all SAs using this connection
#20: deleting state (STATE_QUICK_I2)
#4: deleting state (STATE_MAIN_I4)
#5: deleting state (STATE_MAIN_R3)
DPD: Restarting connection "S_REF_IpsSit******_0"
#21: initiating Main Mode
deleting connection
#21: deleting state (STATE_MAIN_I1)[/FONT]

The connection is "respond only" because there is no way to connect behind the NAT router (without port forwarding), so the log is fine. 

Openswan auth.log
[FONT="Courier New"]DPD: No response from peer - declaring peer dead
#84: DPD: Restarting Connection
#88: rekeying state (STATE_QUICK_I2)
#88: rekeying state (STATE_QUICK_I2)
#88: ERROR: netlink response for Del SA esp.22935e55@ included errno 3: No such process
#88: ERROR: netlink response for Del SA esp.8890980d@192.168.178.10 included errno 3: No such process
#84: DPD: Restarting all connections that share this peer
#84: terminating SAs using this connection
#88: deleting state (STATE_QUICK_I2)
#88: ERROR: netlink response for Del SA esp.22935e55@ included errno 3: No such process
#88: ERROR: netlink response for Del SA esp.8890980d@192.168.178.10 included errno 3: No such process
#84: deleting state (STATE_MAIN_I4)
#89: initiating Main Mode
ERROR: asynchronous network error report on eth0 (sport=500) for message to  port 500, complainant : Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)][/FONT]

The connection got up again after some minutes (~2 - 15min), but I have roughly 20% failures. This is not stable enough for me, so I restart openswan with a delay of 2-3min with a script. I guess this is a design problem of openswan, it wasn't designed with dynamic IPs in mind. I can still resolve the new IP, but ipsec doesn't know about it. I know there was a patch a while ago for openswan, but it is not working stable enough.

If the NAT router got a new IP, I have roughly 40-50% failures! 

Info: I have 4 VPNs (sometimes up to 7) running from this astaro, 3 of them are connected to other Astaro Gateways (v6.315, v7.104, v7.501) and both ends are "initiating" a connection. This connections are running fine with DPD and got up again nearly every time. Only problems with DNS brings them down.

Hi coewar,

my experience is that openswan is not designed with dynamic hosts in mind and NAT brings a lot of trouble. DPD is working and doing what it should do, declaring peers as dead and put some action to the ipsec stack - like hold or restart. But some other problems avoiding the renogiating of the SA, especially behind NAT. I can't pin that exaclty but I guess that there are some paramters for the IKE handshake are not updated correctly. 

For me the best solution is to restart openswan on linux, I'm not restarting anything on astaros side! A restart (stop) brings them down immediately: "deleting connection..., deleting state (STATE_MAIN_I1, STATE_MAIN_I4 and STATE_QUICK_I2)". 

and the start it brings them up again - most of the times within the first attempt.

My script is a very basic bash script for linux, if you are interested I will post it next time I have access to it.

Regards Björn

Thank you, Björn. I would like to see the script or part of it..  you could send it to me privately on this board if you don't want to publish it.

I have built an Amazon Linux router several months ago, and the whole NAT thing was no issue at all. I just had to use the LEFTID setting in OpenSWAN (and MYID) and everything worked without a problem. Astaro's GUI does not let you adjust those settings. I think I will maybe hack it for this instance and see if the issue goes away.

The other thing Astaro is not handling well, is if the remote side is behind a NAT. I believe that is because of another config setting it does not expose which is I think called RIGHTID which you'd set to %ANY%. Because of this, I have to put in the private IP in the VPNID field of a remote gateway's setup. I have a Cisco router that I'm hoping to replace with Astaro instances, and it handles all of this stuff fine. Fortunately I will be migrating to non-NAT'ed VMware infrastructure with the Astaro's, but still can't do anything about some of my peers which are behind NAT's.

Thank you, Björn. I would like to see the script or part of it..  you could send it to me privately on this board if you don't want to publish it.

Hi coewar,

I attached my script to this reply, rename it as you like and run chown and chmod +x on it. You can find some comments inside to setup it for you needs. There are some options for sending emails and log to syslog too. If you have questions...

I have built an Amazon Linux router several months ago, and the whole NAT thing was no issue at all. I just had to use the LEFTID setting in OpenSWAN (and MYID) and everything worked without a problem. Astaro's GUI does not let you adjust those settings. I think I will maybe hack it for this instance and see if the issue goes away.

The other thing Astaro is not handling well, is if the remote side is behind a NAT. I believe that is because of another config setting it does not expose which is I think called RIGHTID which you'd set to %ANY%. Because of this, I have to put in the private IP in the VPNID field of a remote gateway's setup. I have a Cisco router that I'm hoping to replace with Astaro instances, and it handles all of this stuff fine. Fortunately I will be migrating to non-NAT'ed VMware infrastructure with the Astaro's, but still can't do anything about some of my peers which are behind NAT's.

As I understand that, the use of %ANY% is for roadwarrior setups, not for site-to-site VPNs. 

Regards

Thanks. I see that this is to restart the entire services. I was wondering if someone knew how to restart just a specific tunnel using ipsec command. From what I gather, I've only found ways to restart the whole thing.

The %ANY% use I think would be for road-warrior if used in the RIGHT side, but if you put some public IP for RIGHT and then RIGHTID would have a private NAT for those peers behind a NAT, setting that to %ANY% might then allow it to work regardless of the private IP of the peer router.

Thanks. I see that this is to restart the entire services. I was wondering if someone knew how to restart just a specific tunnel using ipsec command. From what I gather, I've only found ways to restart the whole thing.

You can easily change it in the script:

ipsec auto --down ; 
ipsec auto --up ;

This will be best served with a little delay between. But my experience is, that you better restart the whole stack. If you trying to reenable a specific tunnel the same errors will come back. That's why DPD has sometimes no effect. It does the right thing, but the error resist somewhere else in the stack.

And: A restart of ipsec results in a new SA and maybe updated routes. I can restart my openswan within 5-10s, it doesn't affect running ssh connections or a backup on another tunnel! And if the connection with the changed IP is affected, the data flow has been interrupted already.

The %ANY% use I think would be for road-warrior if used in the RIGHT side, but if you put some public IP for RIGHT and then RIGHTID would have a private NAT for those peers behind a NAT, setting that to %ANY% might then allow it to work regardless of the private IP of the peer router.

Okay, but why do you need %ANY% as left on site-to-site? I think left=, right= and rightid=, or rightsourceip= do the trick? Or do I miss something in your setup?