Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Site 2 Site VPN from UTM to XGS (with FQDN)

UTM only supports IKEv1 (so a wildcard gateway address with psk and local\remote IDs configuration has not been tried - this system has over 15 VPN Tunnels)

My XGS has been setup with a proper profile to allow IKEv1 UTM devices to initiate a connection to it, and my XGS has quite a few VPNs setup in respondonly mode

In the case of 1 particular VPN scenario, the remote UTM is behind a dynamic IP

If I set my XGS Gateway Address to the (current) IP of the remote UTM, the connection is established and all works well.

If I set my XGS Gateway Address to an FQDN which resolves (accurately, via DynDNS) of the remote UTM, the connection never establishes, and the log files appear as far as i can see, to be sparse. 

When I use the FQDN in the Gateway Address field, the log file simply says: 

IPSec
Deny Session
(unnamed) - Couldn't authenticate the remote gateway. Check the authentication settings on both devices. (Remote: xxx.xxx.xxx.xxx)



For both of those instances above, I leave the Local ID and Remote ID as not chosen. I have tried setting 1 or both of them statically to an email or a dns host name (and setting the VPN ID on the UTM side to match) but it doesn't appear to help. *in fact, i believe i tried setting them while using the aforementioned numerical IP input above for the Gateway Addrss, and in that case it "breaks" and does not establish the connection, unless i missed a configuration variety, i believe that might relate to the IKEv1 \ v2 from how i read the help file

Leaving the VPN ID Type as IP Address on the UTM Side, but not specifying it, tells it to use the IP address of the interface it is going out of

I am at a loss for why I can't seem to get the XGS to establish a connection when using an FQDN, as the help file says "You can use a DNS hostname when the remote gateway has a dynamic IP address"..but doesn't go so far as to conclude with on a respond only mode in addition to an initiate connection mode.

thanks for any insight



clarification and typos
[edited by: HopefulSoul at 3:54 PM (GMT -8) on 15 Jan 2025]
Parents
  • We found essentially, why it does not work: 

    UTM to SFOS: IKEv1. 
    SFOS in IKEv1 with Respond Only and an FQDN as Remote Gateway requires a "Remote VPN Identifier" to localize the matching PSK. 

    In this scenario, the UTM does not has a local VPN Identifier configured:

    That means, the local Identifier, UTM uses, is the WAN IP of the Star Link --> An IP Address, which can change. 

    If we change the VPN ID on UTM, we break other Tunnels, as they (seems) to be configured using the WAN IPs of the other Interfaces. 

    Therefore we are in the situation of: We know why it is not working, but we cannot fix "all possibilities".  

    __________________________________________________________________________________________________________________

  • Thanks for the resolution, I have configured all tunnels to all sites from the starlink site to use hostnames for the VPN ID. For anyone else reading this, almost all of our sites have static IPs, but the ones that are dynamic, all used UTMs where we could set both sides of the tunnel to INITIATE and we could use either manually changeable IP Host Objects, or DNS Host Objects that would update themselves - as the gateway aspects of the VPNs. All using IKEv1 as the only supported method

    the SFOS in IKEv1 Requiring the Remote VPN Identifier meant the other option to halfway mimic what we had would of been to manually change the VPN ID IP Address on the SFOS device, each time the Starlink Dynamic IP Changed, it wasn't going to "just assume the resolved FQDN IP" was good enough to match\localize to the tunnel

Reply
  • Thanks for the resolution, I have configured all tunnels to all sites from the starlink site to use hostnames for the VPN ID. For anyone else reading this, almost all of our sites have static IPs, but the ones that are dynamic, all used UTMs where we could set both sides of the tunnel to INITIATE and we could use either manually changeable IP Host Objects, or DNS Host Objects that would update themselves - as the gateway aspects of the VPNs. All using IKEv1 as the only supported method

    the SFOS in IKEv1 Requiring the Remote VPN Identifier meant the other option to halfway mimic what we had would of been to manually change the VPN ID IP Address on the SFOS device, each time the Starlink Dynamic IP Changed, it wasn't going to "just assume the resolved FQDN IP" was good enough to match\localize to the tunnel

Children
No Data