Expand ipsec.conf control to webadmin
ipsec.conf has some critical settings for whole device or per site-to-site connection. In particular myid and leftid settings which are REQUIRED when the Astaro is behind a routed network being NAT'ed. This allows you to advertise the real public IP despite the Router's NIC not having that IP. Plus it's already possible, why hinder yourself by hiding something like that? This is a VERY easy thing to do and necessary to make this router more usable behind NAT's.
oh the pain.. when will this silly thing get implemented? In the very least.. allow us to MANUALLY SET the "left" side of the IP address when the router is behind a NAT. That would allow other routers but also including Astaro v8 and v9 to not have to know the private NAT IP and put into the VPN ID field of the other side.
Just this 1 simple thing will finish the IPSec implementation which is so sadly missing. And hacking the configuration is so painful due to how the Astaro system works with the StrongSWAN ipsec.config file.
Larry Prikockis commented
+1 ... I believe I'm running into exactly this problem when establishing an IPSec S2S connection from a Astaro (or rather Sophos UTM9) instance in an Amazon virtual private cloud to a remote network using a Checkpoint firewall.
Given the nature of the Amazon VPC configuration, it would seem that the current UTM9 is always going to end up advertising the private IP rather than the real public IP, thus causing issues for people using the product in the AWS environment.
It is not related to NAT-T. It is a StrongSWAN config setting that is not exposed in the Astaro GUI. The work-around you are suggesting using the VPN ID type for when an Astaro is on the other side is because of the fact that not all the config settings are exposed. If they were, you would not have to do that. #1 - the other party (which might not be in your control) would not have to care about your private IP. And #2 - if we could use the RIGHTID config setting and set to "%" then we might not need to use the VPN ID Type to know what THEIR private IP is. That's useless because the whole point of being behind a NAT is so that you can make whatever internal private IP you need. If "they" change their private IP for their router it should not break the VPN connection if I so choose to allow it. Again, it's all there in StrongSWAN config settings which are not exposed in the Astaro GUI.
Bob Alfson commented
I don't think this is a NAT-T issue, coewar, I think it must be a basic part of IPsec security that rejects packets from "incorrect" sources. You can establish a IPsec VPN with another Astaro behind a NAT. In the Remote Gateway definition for the other Astaro, choose 'VPN ID type: IP Address' and enter the internal IP, not the public IP used in the 'Gateway' field. Doesn't that accomplish what you need?
Forgot one thing. This would not be complete if it also did not carry that into the ipsec.secret file. In the least, if you allow setting the MYID and LEFTID settings, those values have to carry over into the ipsec.secret file for the PSK's to work.
I found someone else asking for this, in a different way!
NOTE: The reason it's REQUIRED is to avoid having the remote party to know the private IP of the Astaro (if they are using an Astaro product themselves.) The other half of this problem is that Astaro is NOT finding the private IP of the router on the other side if it's being NAT'ed, even with NAT-T on. Maybe that NAT-T feature is broken.