IKEv2 source/destination ID'd as WAN interface

HI, I am hoping someone can clarify something for me.

We have SSLVPN and IKEv2 running side by side (migrating to IKEv2). They are both working fine more or less from the remote user standpoint, in that they can access internal resources etc.

However, looking at traffic to/from each of them, I notice SSLVPN traffic source or destination (depending on direction) is shown as 0-SSL-VPN. This interface has an IP address listed as tun0 in the config.

IKEv2 source/destination is just shown as the WAN interface. There is no tun# and no interface IP for this subnet.

This poses an issue where some traffic to IKEv2 clients initiating from within the datacenter (say, our desktop management server, or software deployment) is unable to reach the IKEv2 since it is blocked by an outbound->Any External policy (blocking certain traffic from our servers to the internet, SMB for example). SSLVPN clients do not have this issue.

Similarly, I need to disable NAT on the IKEv2 outbound traffic, otherwise packets arrive at the endpoint with the WAN IP, and so the endpoint can't send them back (IE, pings from an internal server are natted as to the external IP and obviously responses then by pass the VPN)

Yes, I can move the rule that allows outbound traffic to IKEv2 users above the blocking rule, but I'd rather than the IKEv2 traffic not be labelled as external by the firebox.

I can find no option to remedy this other than the workaround of moving the rule.

So, why is SSLVPN traffic given its own interface (0-SSL-VPN) and IKEv2 just using the WAN interface? Is this just how it works by nature, or can I configure, say, a 0-IKEv2-VPN interface? I should note we are using split tunneling with IKEv2, although not supported and perhaps this is why.

Comments

  • james.carsonjames.carson Moderator, WatchGuard Representative

    IKE (IPSec) and SSL VPNs are handled by different portions of the firewall. IKE is done in hardware via a crypto accelerator (except on small devices, or virtual devices,) while SSLVPN is sent into a Tunnel Adapter (just like on a PC or MAC that it's installed on.)

    There's also a rule (if you go to VPN -> VPN Settings) to allow outbound IPSEC traffic, which IKEv2 falls under. The firewall does not allow this by default, and it must be checked.

    -James Carson
    WatchGuard Customer Support

  • edited July 2020

    @James_Carson said:
    IKE (IPSec) and SSL VPNs are handled by different portions of the firewall. IKE is done in hardware via a crypto accelerator (except on small devices, or virtual devices,) while SSLVPN is sent into a Tunnel Adapter (just like on a PC or MAC that it's installed on.)

    There's also a rule (if you go to VPN -> VPN Settings) to allow outbound IPSEC traffic, which IKEv2 falls under. The firewall does not allow this by default, and it must be checked.

    Hey thanks! That absolutely clears it up.

    So, would enabling "allow outbound ipsec" help me in this instance, is that more for allowing clients to initiate an IPSEC/IKEv2 connection from inside the firewall?

  • james.carsonjames.carson Moderator, WatchGuard Representative
    edited July 2020

    All enabling it does is creates a rule in your firewall policies (you can click it, and you'll see an outboud IPSEC policy appear.)

    You can create your own, or use one you already created. It just needs to allow
    ports 500 and 4500 UDP
    protocols ESP and AH.

    -James Carson
    WatchGuard Customer Support

  • edited July 2020

    OK thanks for your assistance here, much appreciated

Sign In to comment.