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. 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.  Check out thread about Astaro VPN with NAT.

https://community.sophos.com/products/unified-threat-management/astaroorg/f/58/t/54446

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.

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.

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.