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

Thread Info
  • State Suggested Answer
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 39 subscribers
  • Views 221 views
  • Users 0 members are here
Options
Suggested

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

HopefulSoul

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
  • 0

    Assuming, 

    * no remote access IPsec configured on SFOS (as it uses also uses * for remote gateway) or

    * not more than one s2s policy based IPsec tunnels with remote gateway as * on any given local gateway port (ex: local gateway=Port2, remote gateway=*),

    when UTM with dynamically assigned ip initiates S2S IPsec tunnel (ikev1+psk) to SFOS having IPsec config with remote gateway = *, then tunnel should come Up. No need to use ID fields as it is not supported/used in IKEv1.

  • 0 in reply to Sreenivasulu Naidu

    apologies i should have fleshed out my wildcard thought in the first sentence more, in that, without being able to utilize ID fields, i would not want to try using the wildcard *, as in the current state i wouldn't know in the future if i would add any VPNs Site2Site elsewhere

    ALSO, and more damningly for this use-case, (going into more detail i wanted to avoid for confusion sake with the whole scenario, but is now necessary) ..on this XGS I have 4 VPNS setup from this site to the remote site. This is because both sites have 2 WAN circuits, and in the case of 1 going down on either side, the 4 RespondOnly VPNs include 3 backups "in waiting". So in this case, at least 2 would need the Wildcard (*) address (to account for the WAN circuit remotely that is dynamic). While this should work, since the localport would be different on the XGS for the 2 respondonly VPNs that would have the wildcard, ultimately i want to prevent future missteps if anyone else works on this or i forget about this unique setup amongst our 15 sites, and i just want to know why the dang feature doesn't seem to work as it should with a FQDN :) 

    (realistically that last part is tickling my brain the most)

    There are quite a few screenshots we could get into here, and i will provide on request but here are some for starters (redacted)- 

  • 0 in reply to HopefulSoul

    Basically: Starlink sounds like it is the problem here. 
    Starlink does not offer a "real IP". You are behind a GCNAT in Starlink, which means, the IP you get via DDNS is not really yours. 

    Try to check in the packet capture of SFOS to check for Port500 and Port4500. You should see packets. 

    __________________________________________________________________________________________________________________

Reply
  • 0 in reply to HopefulSoul

    Basically: Starlink sounds like it is the problem here. 
    Starlink does not offer a "real IP". You are behind a GCNAT in Starlink, which means, the IP you get via DDNS is not really yours. 

    Try to check in the packet capture of SFOS to check for Port500 and Port4500. You should see packets. 

    __________________________________________________________________________________________________________________

Children
  • 0 in reply to LuCar Toni

    right, but the DDNS is setup to register from the UTM using starlink (where that WAN is obvi dhcp) and so as mentioned, if in the XGS firewall, i put the GCNat'd Starlink IP, the connection establishes and works. 

    I just don't understand why i don't see any MORE info in the log file on the XGS fw than mentioned in the first post, when i remove the IP and put the DDNS entry, it shouldn't affect the UTM hitting the XGS (tldr; i expect packets, since the only log on the XGS indicates the IP)

    oh, i forgot to mention, in the first post, where i put the xxxx that was me masking the IP, i see where that's confusing...but since i typed all of the above, im going to be lazy and leave it haha

  • 0 in reply to HopefulSoul

    The object on SFOS: The FQDN, does it resolve to the IP or not? 
    You can check this in SFOS webadmin under Host and Services - Check for the FQDN Host and mouse-over. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    tldr; there is an FQDN entry that does resolve. The wording of your question makes me wonder a few things though

    since the XGS IPSEC S2S VPN  setup has a manual entry, and does not use objects like the UTM does,

    1) why would there even need to be an entry in hosts and services? Because i had to manually input \ type the IP\FQDN in the vpn setup, i expected XGS would use configured public dns to resolve


    2) is the XGS VPN field, with text entry for fqdn, looking for the NAME variable of the hosts and services entry, or will it still look for any FQDN variable of any hosts and services entry (tld(id)r; would i need to make the name match the fqdn to make the vpn work?)

  • 0 in reply to HopefulSoul

    Do you have other tunnels in use on this Firewall? Because you could also use the * (Wildcard) as remote gateway to try it with this. 

    SFOS can pickup the wildcard here and resolve by using the PSK. But Wildcard will change ALL PSKs, which have a Wildcard. 

    About your questions: The Object here is simply to double check, if the appliance is even able to resolve the DDNS entry or not. 

    The IPsec config is not related to the FQDN Host tables. It is a separate daemon, but this way is a quick way to doublecheck, as most customer have this object already created. 

    __________________________________________________________________________________________________________________

Unfiltered HTML