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.