no https (or other secured traffic that does SSL handshake) available over AutoVPN

[thomasthomsen]

Just wanted to see if other persons in the world have this problem.

And it is strange .... 

AutoVPN between two networks (nothing fancy as such), all good, except when we try to reach, for example, a https service on the other end.

The TCP handshake to the server is just fine (so nothing is blocked by an ACL) but then, when the cert is sent, it disappears somewhere in the MX. We can see the packet going into the LAN interface, but nothing received on the other end, or in the tunnel.

Now here is the funny part, if we then whitelist the server (Group policy Allow list / Whitelist on the client page) everything works.

IPS would be the first thing we would look at, but nothing shows up as blocked in IPS, and disabling IPS does nothing, only "allow list / whitelist".

Have anyone seen that before ?

/Thomas

[PhilipDAth]

Smells like time to do an MX firmware upgrade ...

[thomasthomsen]

So its something people have experienced ?

[thomasthomsen]

Does whitelist / allow policy mess with the DF bit on packets ?

We actually think the SSL handshake is being send with DF bit.

And if it drops that traffic because of MTU, and the whitelist / allow policy ignores the DF bit then everything makes more sense to us.

[thomasthomsen]

And PS: yes , we have upgraded, downgraded and so on ... nothing helps.

Only whitelisting / allow policy on the client page helps.

[PhilipDAth]

I think it is improbably, but try lowing the MTU on a test machine.

You need to find the name of the network adaptor being used with this command:

netsh interface ipv4 show subinterface

Then run this command to change the MTU (change "Local Area Connection" to the adaptor name above):

netsh interface ipv4 set subinterface “Local Area Connection 2” mtu=1300 store=persistent

[thomasthomsen]

But isn't it strange that immediately when we set a server on the allowed list, everything works.

We actually set up a new network to the same Concentrator, same type of hardware, same config, and that just works.

Its very very strange.

[thomasthomsen]

Ok -.... here's a hint to our problem - Content filtering - When the MX cant reach Brightcloud services (that is not described as required on the "firewall info" page).

I'll just leave this here, and then people can PM me if they want to know what I think about this, the strange way the MX apparently handle this, what you can see in the event log (on any log for that matter) *hint:Its nothing*, and what I think of Merakis support right now.