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

PLEASE some way to override the ipsec.conf "Left=x.x.x.x" setting

We're running a UTM appliance in an Amazon (AWS) VPC and trying to establish an IPSec VPN tunnel with a remote site.   Because of the way in which AWS manages public IP addresses, the UTM interface basically does not "know" the public IP and as a result, identifies itself using the private IP address.

 With certain remote vpn/firewall products (apparently recent Juniper models for instance) this prevents phase 2 from completing because the peer IP (public) does not match what the UTM is sending as the VPN ID.

 Effectively, I need to be able to go in and edit the strongswan config file to set Left=x.x.x.x where x.x.x.x is the PUBLIC IP for the UTM.   The UTM gui however offers no way to do this.

See for example: feature.astaro.com/.../2506490-expand-ipsec-conf-control-to-webadmin   (submitted back in 2012!)

Is there some way to override this behavior and "manually" modify the strongswan ipsec.conf file directly?   If not, this limitation basically prevents us from using the UTM's IPSec capabilities when the other side is using recent firewall devices.  The workaround in the past has been to ask the other side to enter our private IP as the VPN ID ... aside from being silly (the whole point of NAT is that the other party shouldn't HAVE to know or care what my private IP is), it also flat-out isn't possible in some scenarios.

thanks in advance for any ideas or hints!



This thread was automatically locked due to age.
  • The classic solution for this is to have your correspondents configure their endpoint to be the equivalent of "Respond only" and to use a PSK. Is that a possibility?

    You can make a change at the command line, but that's not supported: community.sophos.com/.../198686

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Thanks Bob. Unfortunately, while the solution of having the other end alter their configuration as you suggest is our usual route, this time I've hit on a customer that won't/can't do that. I've been dreading this day and hoping Sophos would deal with this issue before I was forced to decide between a customer and this damn frustrating but occasionally brilliant piece of software.

    I'll take a look at that thread re: making changes at the CLI.... If that will solve my problem I'm fine with it. After all, all I've gotten in the way of support from Sophos on this issue is: "you can't do that. Sorry for the inconvenience". So they haven't exactly left me with any "supported" options :(
  • ugh... so the unsupported solution doesn't seem to work properly for me either.

    If I follow those instructions and add the " leftid="xxx.xxx.xxx.xxx" to ipsec.conf-default (where xxx etc is my public IP for the UTM) and then also add the equiv. left in ipsec.secrets-default I end up breaking every other VPN connection that is happily working with the non-NAT'd private IP.

    e.g.,

    this snippet from ipsec.secrets:
    172.25.148.85 aaa.aaa.aaa.aaa : PSK 0seU83eTlrV3k4U2Vt
    172.25.148.85 bbb.bbb.bbb.bbb : PSK 0sV3h2YktlRVZoc1pUdmVHOCM=
    xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy : PSK 0sTWFweGhwN3c=

    so currently the 2 connections to aaa and bbb work fine (note that the UTM has "helpfully" configured the left IP to be the internal, private IP for itself even though I want it to be using the public IP.

    If I go and change the left IP to the correct public ip for the last case xxx.xxx.xxx.xxx (this is the connection that I'm having troubles with because they CAN'T/WON'T set the VPNID to 172.25.148.85 at their end), it may very well work for them (haven't had the chance to test it yet), but now, all the other connections break with a lot of:

    2016:02:04-10:03:26 qcpfw pluto[7285]: "S_REF_IpsSitChildMinne_2" #421: responding to Main Mode
    2016:02:04-10:03:26 qcpfw pluto[7285]: "S_REF_IpsSitChildMinne_2" #421: Can't authenticate: no preshared key found for 'xxx.xxx.xxx.xxx' and 'yyy.yyy.yyy.yyy'. Attribute OAKLEY_AUTHENTICATION_M

    So it seems even if I go in and hack these files manually, I can't change this setting for just a single tunnel without impacting the others. Given that I have 20 or so working tunnels on this device that seem to manage ok even with the dumb UTM advertising the private IP, I'm at a loss as to how to make it work for this one new one.

    Waiting on a call back from a "senior Sophos engineer" to discuss further... but so far, they've been standing by their "oops... sorry for the inconvenience" stance :(

    If anyone in the community has a brilliant fix for this mess (other than switching to a different product, which believe me, is on the table long term) I'd be grateful for any ideas.

    thanks
  • you can set you own ID in GUI on IPsec/Advanced - but for all IPSe connections, not a single one.
    IT's helpful sometimes if your UTM is behind da NAT device
  • what version of the software are you running?   I don't see that option under the Advanced tab on mine.

  • 9.317-5 and 9.353-4 have the option
  • awesome!   Too bad Sophos support doesn't think this works :)  

    "The VPN ID and the Left ID are different. In most cases, setting the VPN ID in the section as described does allow VPNs to connect through NAT. I did briefly mention this in my first email, but I understood this as a scenario where you needed to specifically set the left ID. Sorry about that."

    I've just verified on a test case though that changing that setting does exactly set the leftid= parameter in the strongswan config.   I guess the user community knows more about this product than the people who sell it :)

    thank you!

  • That is new! Have you tried this or otherwise confirmed that the 'VPN ID' there is indeed the "leftid?"

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I've confirmed that setting that updates the leftid="..." parameter (or rather ADDS it) to ipsec.conf and also uses this ip value in secrets.conf. Looking very promising! Unfortunately, my UTM is quite a few updates behind so I need to schedule time to update before I can actually try it "live".
    I did update the related feature request here: feature.astaro.com/.../2506490-expand-ipsec-conf-control-to-webadmin since this fix appears to directly address that request.