E84.20.6108 Remote Access VPN-Blade wrong DNS (no traffic split)

[Karl-Hermann]

Hello all,

I have the following problem:

When a user connects his laptop via his private WiFi AP to the corporate network, everything is fine. If he uses his private wird LAN, he can access resources in our network via IP, but not DNS based. If he connects a additional network adapter via USB it works over this adapter. 

When I have a look into the DNS cache I can see that the DNS resolution is done against our public DNS server (which does not cover most of our internal resources). As we do not use the traffic split feature, all traffic should be routed through the tunnel.

This behavior is reproducible and can be found by several of my test users with E84.20.6108.

E83.30 has no problem with that.

Thanks a lot

Karl-Hermann

[PhoneBoy]

Have you opened a TAC case here?

[Karl-Hermann]

I am sorry, but no. We have no direct support @ CP. It will be done via our managed service and their wholesaler.

[PhoneBoy]

Recommend having them do so.
I know there was at least an issue with the client disconnecting in this release that is fixed in the upcoming E84.30 which is due out shortly.

[gkaufman]

We are actually experiencing this issue on E84.30 in our environment.  It is not everyone and seems to be isolated to a specific ISP (which doesn't make much sense), but older versions were working, and if we manually roll back versions to say E83.00 for example, it works without issue.  It is just not in the cards to roll back 600+ users manually.

We have opened a TAC case for this, so we will see what they say.

We were in the process of upgrading folks from older about to be un-supported versions, and now we are having this issue.

If anyone has any insight while we wait for a resolution from them, please let me know.

[Amir-Yacoby]

Hi all,

We are familiar with the DNS issue over LAN and have a fixed version for E84.20.

We are also currently working on a fix for E84.30.

Please create a Service Request and we'll provide the package.

[Paul_Starr]

We noticed this issue to be related to when the wifi and check point adaptor have the same interface metric. 

*ethernet 2 being Check Point VPN

We have been able to work around this issue by changing the priority of the Check Point Interface either by changing the Check Point adaptor to a lower number, making it priority when connected via PS command or GUI change: 

Set-NetIPInterface -InterfaceIndex 19 -InterfaceMetric 10 

--- Where Index is the Index number seen in Get-NetIPInterface. 

Or via the GUI by

• Change Adapter Settings
• Ethernet2 (Or whichever interface is configured as the Check Point VPN interface)
• IPv4 > Properties
• Advanced > Interface Metric

[Lior_Arzi]

As stated before, Check Point support has a fix for this issue.

It was identified only after E84.30 was released, so the issue was fixed in E84.40 (will be released soon) and we build a fix for earlier versions.

the issue is present on E84.20, E84.30 (and possible also on E84.10, need to check).

to resolve:

- you can contact support to get a fix for any of the effected version.

- you can use the latest recommended version - E84.00

- you can move to E84.40 that will go out soon and already have this fix integrated.

if you are already on E84.20/30 and need an immediate solution, you can contact our support and they will give you the relevant fix.