SSLVPN - User cannot print to IPV6-based printer port (Split tunnel)
Hello-
While I wait for our glorious support options to respond, I had a question for the community.
I have a client who we have configured with SSLVPN to access a RemoteApp. This connectivity is working fine, they are in split-tunnel mode and the local Internet and ipv4 networking is having no connectivity issues. Their local ipv4 LAN does not conflict with any configured subnets on our Sonicwall and there are no routes that are in conflict as a result. The customer works from home.
The customer is using an HP printer which is, by default, using an IPV6 port to send jobs. It appears that the driver software opts to use the Link-local IP for the printer and this works fine - unless the customer is on the SSLVPN. While connected, any prints they send go to the queue and just…sit there. There don't seem to fail, they just don't even process…unless you disconnect the SSLVPN. Once disconnected, all those queued print jobs process normally.
I have moved the port to an ipv4 port and found that the issues goes away, but the client would like to keep the ipv6 configuration and honestly, so would I, since it won't require making changes to their local home network to create an out-of-scope static addressing on the printer, or a reservation/exclusion in their DHCP range(we prefer not to make changes to home environments.
My questions is - why won't the ipv6 traffic seemingly pass while the SSLVPN is connected? I did verify that our Client Settings have no ipv6 range configured and I suspect that is likely the culprit, but I'm not sure. I can't easily configure the ipv6 range as this Sonicwall is hosting multiple production environments through SSLVPN, but I could do it after hours if that makes sense as the next step.
Any ideas?
Thanks!
-Steve
Answers
I am assuming the problem is the use of the Link-local ipv6 IP as the port - done by HP configuration utility, since link-local is not routable I wonder if the communication is broken by the SSLVPN software somehow - but I can't seem to discern why it would work when not connected, even if it is link-local, but not when the SSLVPN is connected (which doesn't hand out Ipv6 at present and isn't setup to route it…)