Implications of disabling the built-in IPSec policy
Don't ask me why but I have an office that want to use an internal network L2TP VPN server for their external/mobile users to connect to.
The only way I been able to get this to work is to disable the built-in IPSec policy by going VPN > VPN Settings > untick Enable built-in IPSec policy.
Can you tell me if there is either a better way to allow this to work or what are the implications leaving the built-in IPSec disabled?
Will it stop my branch office VPN's between offices or BOVPN Virtual Interfaces used by my Azure VPN from working? Or will it stop anything else from working?
Many thanks.
0
Sign In to comment.
Comments
Hi @MattHX
Disabling the built in IPSEC policy will stop the firewall from terminating IPSec connections on the firewall itself.
-If you have one external IP address, this will (for the most part) break IPSec to/from the firewall itself.
-If you have multiple external IPs, you can make a new policy to forward a specific IP to the firewall, and a different IP to the L2TP server.
To do that, you'd need to add a new policy (expand packet filters, and find IPSec). Make the policy from any-external to the IP you want the firewall to listen on.
Make another policy from any-external to the 1-1 NAT or SNAT that you want to forward the server based L2TP on.
I'd suggest exploring the L2TP VPN service on the Firewall first, and see if that fits your needs. It works with most mobile devices, and doesn't expose ports of your server to the internet to do it.
-James Carson
WatchGuard Customer Support
Thanks for the great reply @James_Carson
I definitely want to get them on the L2TP VPN service on the Firewall eventually but that might be a bit of a longer battle as they want to stick with what they know and I'm introducing change a bit at a time and getting this working in the short term as a stop gap.
So will disabling the built in IPSEC policy stop the BOVPN's to the other offices (also WG firewalls) and BOVPN Virtual Interfaces to Azure from working? They use a Pre-Shared Key option, not the IPSec Firebox Certificate option.
I did a quick test and it didn't seem to drop them but not sure if it would prevent them rekeying if they dropped.
They don't have multiple external IPs so thats not an option I'm afraid.
Given what James said, and what is in the docs (see below), I would expect the BOVPN tunnels to stop, or at the least, not be able to start up once stopped.
Disable or Enable the Built-in IPSec Policy
The Firebox includes a built-in IPSec policy that allows IPSec traffic from Any-External to Firebox. This hidden policy enables the Firebox to function as an IPSec VPN endpoint for Branch Office VPN and Mobile VPN with IPSec tunnels. The built-in IPSec policy has a higher precedence than any manually created IPSec policy. The built-in IPSec policy is enabled by default. To disable this policy, clear the Enable built-in IPSec Policy check box. Do not disable the built-in policy unless you want to create another IPSec policy to terminate a VPN tunnel at a device other than the Firebox, such as a VPN concentrator on the Firebox trusted or optional network.
If you clear the Enable built-in IPSec Policy check box, you must create IPSec policies to handle inbound VPN traffic to the Firebox and any other VPN endpoints.
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/bovpn/manual/global_vpn_settings_about_c.html
@Bruce_Briggs
The tunnels can end up in a state where they'll start /if/ the firewall starts the tunnels, but if they're started from the remote side, they'll fail (with an error from that side like message retry time out, or similar.) Things like rekeys or connection blips from the remote side will also break the tunnel. It'll sort of work, but make an overall bad experience.
-James Carson
WatchGuard Customer Support
@MattHX
It'll break all tunnels (IPSec Mobile, or Site to Site.) In order to get it working again, you have to re-check that box (which just makes a hidden policy that says.
Any-External -> Firebox (for ESP, AH, port 500/UDP and 4500/UDP)
[Firebox is just an alias for every IP the firewall owns.]
Established connections will continue, and any tunnels initiated by the firewall may continue, but anything coming from the other end will end up in the bit bucket.
By disabling the rule and making a rule like
Any-External -> 65.66.67.68 (made up IP) (for ESP, AH, port 500/UDP and 4500/UDP)
You're telling the firewall to only listen for IPSec Traffic on 65.66.67.68 instead of every IP it owns.
You can then make another rule with
Any-External -> (SNAT) 65.66.67.69 - SNAT -> 192.168.111.100 (internal L2TP server)
Which would effectively make any IPSec traffic pointed at 65.66.67.68 terminate at the firewall
and
any traffic pointed at 65.66.67.69 at the L2TP server.
-James Carson
WatchGuard Customer Support
Thanks for the great replies @James_Carson and @Bruce_Briggs
That pretty much kills this for me then if its going to break the BOVPN's as all our servers are in Azure so we need that BOVPN to Azure.
Though it could be a blessing in disguise as it will force them to go for the L2TP MUVPN service on the Firewall sooner. So I've just set this up and been doing some tests. I was hoping it would be able to use the SSO AD authentication but it looks like L2TP MUVPN can only use FB-DB or Radius. So I might have to create a user on the FB-DB for every user. Either that or use a IPSec MUVPN with the Shrew Soft client which if I remember correctly can use SSO AD authentication. But the Shrew Soft client would be a bigger user facing change to the native Win10 VPN client so I don't think they'd go for that.
Hi @MattHX
SSO is a service that runs and logs local users into the firewall for logging and policy selection purposes -- it copies the user's windows login data to the firewall using a few helper processes.
The VPNs log in directly by themselves -- there's no SSO there.
-L2TP and IKEv2 can log in via RADIUS or Firebox-DB. If you want to use Active Directory with either, you can use the NPS (Network Policy Server) role in Windows to act as a RADIUS server and tie those together.
-SSLVPN and IPSec (IKEv1) VPN can bind to AD directly.
-James Carson
WatchGuard Customer Support
James, Bruce,
Thank you for the insight. I also need to disable this option but can't risk breaking our BoVPN Virtual Interfaces on which we rely so heavily. So, if I understand correctly the above - in order to effectively maintain the BOVPN Virtual Interfaces reliably connecting in both directions and still remain obfuscated from unauthorized/unwanted IPsec request traffic such as PCI-DSS scanning of our public IPs I can effectively disable the built-in IPsec rule and create a manual rule such as:
[Known BoVPN Public IPs (or Alias)] -> Firebox (for ESP, AH, port 500/UDP and 4500/UDP)
So the firebox will only RESPOND to IPsec traffic from our pre-configured branch office public IP addresses (as well as reliably initiate tunnels outbound) and effectively ignore IPsec traffic from any other source (PCI DSS scan source networks)...?
If yes, then as a follow-up question: Given that we have a 10+ remote locations and most locations have 2 internet circuits with static public IP addresses (for failover purposes); Is it more efficient from a compute/performance perspective on the firebox - for me to set up Aliases or to simply list 20+ IP addresses directly into the rule?
From a cosmetic perspective I would probably prefer the Alias approach to keep the view reasonable and intuitive.
Again, Thank you for the insight...