HTTPS errors accessing web sites from SSL VPN after v15 to v16 upgrade

Miroslav,

can you share a screenshot of the error message you get? Also can you share the policy rule applied to SSL VPN users?

Thanks

Before the upgrade, when connected to SSL VPN, I could browse normally RD WEB ( or any HTTPS web on the remote network ), now I'm getting error, because Sophos is intercepting HTTPS traffic:

HI MiroslavCacija, 

is the Certificate applied on the SSL VPN policy same as the Certificate Prompt while accessing the WEB URL Via SSL .?

Yes, appliance certificate.

Hi Miroslav,

Please post the SSL configuration screenshots. Refer #1 in my guide here. Any catch?

Thanks

Edit

Hi Miroslav,

In the VPN_LAN rule, uncheck the "match known user" option. Also make VPN Source Network > ANY.

Configure a LAN_VPN FW-rule (without MASQ selected) and same conditions as in the VPN_LAN rule. 

Did you check #1 in the guide I mentioned. If you want this thread to get towards resolution, we would require the backend logs as suggested.

Thanks

Sachin,

The rule he created seems correct. Why a LAN to vpn policy rule is needed? Also why the match know users should break the firewall rule?

I do not understand your point of view. If your suggestions make the https works , this is not a normal behavior. It does not make sense!

Sorry about that!

lferraraa absolutely. I don't understand why, just after the upgrade something that was working perfectly, now doesn't works. Why should I change policy, if it was working without problems just before the upgrade ? HTTPS scanning is disabled, but still this type of traffic gets intercepted, and I cannot connect to any HTTPS site over VPN ... I'll contact support, as it seems that there is no configuration errors here in my case ... 

Hi Luk,

We require bidirectional rules to process traffic in both conditions, monitor the traffic through packet capture option in XG you can see that LAN_VPN traffic might not be forwarded out. Again, it will be a great learning curve if the traffic does route out with v16. But my takes on this will be to create one more rule that I feel is missing "LAN ANY VPN without MASQ". The match known user option is not required as the initial authentication (when

The match known user option is not required as the initial authentication (when connection is made from SSL client to XG) is managed by an intermediate PAM module which interacts with the VPN authentication and Access Server. So the User traffic is authenticated by default. Specifying the user match inside a FW-rule is not required.

Hope that clears the doubt.

Thanks

Hi Luk,

We require bidirectional rules to process traffic in both conditions, monitor the traffic through packet capture option in XG you can see that LAN_VPN traffic might not be forwarded out. Again, it will be a great learning curve if the traffic does route out with v16. But my takes on this will be to create one more rule that I feel is missing "LAN ANY VPN without MASQ". The match known user option is not required as the initial authentication (when

The match known user option is not required as the initial authentication (when connection is made from SSL client to XG) is managed by an intermediate PAM module which interacts with the VPN authentication and Access Server. So the User traffic is authenticated by default. Specifying the user match inside a FW-rule is not required.

Hope that clears the doubt.

Thanks

Thanks sachingurung but you are adding confusion...

A LAN to VPN is needed....why? It is like, in order to be able to surf on internet a LAN to WAN and WAN to LAN rules are needed.

Also, if the match know user is not needed because the authentication is already done by another process, make sure to:

• remove the match know user option when VPN zone is inside the rule or
• leave the option enabled (so even if the users enabled it) the rule works

Dear Saching, on UTM9 everything was working as expected...on XG sometimes "strange" rules and behaviour are happening and this adds a lot of confusion to young XG users but even to expert users.

This is an implicit aspect that XG has to improve a lot! I do not like this at all! Because I am used to think about logically before implementing any new configuration/modification on every appliance (Cisco, Fortinet, Sophos, etc...). Here the logic does not work anymore.

Without your intervention, no one were able to find the right configuration (maybe drop-packet capture would help the troubleshooting).

So make sure to guide users using the UI alerts/messages or KB ( I have wrote this many times here on community) and make sure that XG uses the same logical view like other Leaders UTM products.

This will improve our sales and consideration on Sophos XG. The strengthness of UTM9 was the semplicity and logical workflow...on XG is still missing.

So please make sure to pass this concept internally. We are waiting for better product on v17.

I feel we are going in wrong direction. VPN works perfectly fine with this set of rules ( and it was working exactly I wanted to in previous firmware ), even now I can access any server via RDP, I can access network shares, I can browse HTTP web on remote network, but ONLY when I try to browse HTTPS site, I'm unable to !

HTTPS is the problem, Sophos intercepts HTTPS traffic in VPN, and there is no obvious reason for it to do that !

What's the fuzz about "bi-directional rule requirement" ?
If packets didn't make it back, TS simply wouldn't get a certificate error.

Why is the masquerade required on the VPN->LAN rule ? Try without it.
Also try adding in "Web -> Exceptions" an https decryption exception for internal server name.

sixteen again said:

Why is the masquerade required on the VPN->LAN rule ? Try without it.
Also try adding in "Web -> Exceptions" an https decryption exception for internal server name.

Tried, but still the same... thx.