Share Port 443 between Mobile VPN with SSL, Access Portal and HTTPS websites

What's the best/recommend way to share port 443 between Mobile VPN with SSL, Access Portal and web site resources behind the firewall using https/port 443?
I am looking to transition fully to the Access Portal but still need to allow remote access to file shares (so Mobile VPN with SSL OR IKE) is needed.
I thought I read a posting somewhere what WG recommends moving the Mobile VPN to port 53 but that sounds....like a bad idea...

Comments

  • WG used to recommend using UDP port 53 for SSLVPN, prior to DNSWatch.
    If DNSWatch is enabled, TCP/UDP pot 53 no longer works for SSLVPN.
    You can specify any port for SSLVPN, but there us no guarantee that access will work when behind someone's firewall, which is why one often uses a commonly allowed port.
    At the moment, I am using port 553. But I don't need to use it too often.

  • I have DNSWatch enabled so moving SSLVPN to UDP port 53 won't work..I also have users who frequently use other organizations networks and moving to a port other then 443 sounds like its going to cause issues.
    Guess I'll look into moving away from SSLVPN to IKEv2...

  • james.carsonjames.carson Moderator, WatchGuard Representative

    @BrianSteingraber They can exist on the same port, it just requires the https:///sslvpn_logon.shtml to get to the SSLVPN page. Since most customers have the client pre-installed or get it from WatchGuard.com's downloads, they'll honestly never even see (or need to see) that page anyways.

    Going to https:// will just get you the access portal.

    -James Carson
    WatchGuard Customer Support

  • Thanks @James_Carson. So with both SSLVPN and the Access Portal using 443. Is it possible to access an internal website via 443 from outside (assuming NAT is used)?

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @BrianSteingraber
    You'd only be able to do that using two external IPs, or by changing the port of the SSLVPN/Access portal. The firewall can do content actions, but only to different IPs behind the firewall, and not to itself.

    (Example: HTTPS Proxy Action with an HTTP Content Action)
    https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/proxies/examples/content_action_https.html

    Since the access portal and SSLVPN are internal tools, it'd probably be best to leave the webserver on 443/TCP, and put the SSLVPN/Access portal on something like 444/TCP. This means the users would have to type in https://:444, but once they have that bookmarked, it's not a big deal.

    Thank you,

    -James Carson
    WatchGuard Customer Support

  • The website leverages a specific dns/hostname and additional IP separate from the SSLVPN IP.

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @BrianSteingraber
    So long as the website policy is above the SSLVPN policy, traffic destined to the webserver should still go to it, and any remaining traffic will fall to the SSLVPN/Access portal policy.

    You can also edit the FROM area of the WatchGuard SSLVPN policy to just have the IP you want it to use in the TO area in stead of "Firebox" -- Firebox is just an alias for all the IPs the firewall owns.

    -James Carson
    WatchGuard Customer Support

Sign In to comment.