After upgrade form latest v15 to latest v16 ( SFOS 16.01.1 ), when connected remotely via SSL VPN, and trying to access any HTTPS site in remote network, I'm getting errors and cannot access any site. HTTPS scanning is disabled for VPN connections, but Sophos still intercepts HTTPS traffic when comming from VPN. Am I missing something ?
In v15 this was working normally, never had a problem with this.
console> tcpdump "host 10.81.234.6 and port 443"
tcpdump: Starting Packet Dump
10:11:10.317186 tun0, IN: IP 10.81.234.6.55420 > 172.16.3.71.443: Flags [S], seq 1831438675, win 65535, options [mss 1340,nop,wscale 3,nop,nop,sackOK], length 0
10:11:10.317255 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55420: Flags [S.], seq 41718827, ack 1831438676, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
10:11:10.338872 tun0, IN: IP 10.81.234.6.55420 > 172.16.3.71.443: Flags [.], ack 1, win 32768, length 0
10:11:10.340042 tun0, IN: IP 10.81.234.6.55420 > 172.16.3.71.443: Flags [P.], ack 1, win 32768, length 232
10:11:10.340059 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55420: Flags [.], ack 233, win 237, length 0
10:11:10.616718 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55420: Flags [.], ack 233, win 237, length 1340
10:11:10.616727 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55420: Flags [.], ack 233, win 237, length 1340
10:11:10.616731 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55420: Flags [P.], ack 233, win 237, length 2
10:11:10.639690 tun0, IN: IP 10.81.234.6.55420 > 172.16.3.71.443: Flags [.], ack 1341, win 32768, length 0
10:11:10.640235 tun0, IN: IP 10.81.234.6.55420 > 172.16.3.71.443: Flags [.], ack 2681, win 32768, length 0
10:11:10.640700 tun0, IN: IP 10.81.234.6.55420 > 172.16.3.71.443: Flags [.], ack 2683, win 32767, length 0
10:11:10.707621 tun0, IN: IP 10.81.234.6.55420 > 172.16.3.71.443: Flags [F.], seq 233, ack 2683, win 32767, length 0
10:11:10.707706 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55420: Flags [F.], seq 2683, ack 234, win 237, length 0
10:11:10.709607 tun0, IN: IP 10.81.234.6.55421 > 172.16.3.71.443: Flags [S], seq 3670170337, win 65535, options [mss 1340,nop,wscale 3,nop,nop,sackOK], length 0
10:11:10.709663 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55421: Flags [S.], seq 2402212776, ack 3670170338, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
10:11:10.729120 tun0, IN: IP 10.81.234.6.55420 > 172.16.3.71.443: Flags [.], ack 2684, win 32767, length 0
10:11:10.731214 tun0, IN: IP 10.81.234.6.55421 > 172.16.3.71.443: Flags [.], ack 1, win 32768, length 0
10:11:10.732186 tun0, IN: IP 10.81.234.6.55421 > 172.16.3.71.443: Flags [P.], ack 1, win 32768, length 232
10:11:10.732211 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55421: Flags [.], ack 233, win 237, length 0
10:11:10.927134 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55421: Flags [.], ack 233, win 237, length 1340
10:11:10.927139 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55421: Flags [.], ack 233, win 237, length 1340
10:11:10.927144 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55421: Flags [P.], ack 233, win 237, length 2
10:11:10.950557 tun0, IN: IP 10.81.234.6.55421 > 172.16.3.71.443: Flags [.], ack 1341, win 32768, length 0
10:11:10.951243 tun0, IN: IP 10.81.234.6.55421 > 172.16.3.71.443: Flags [.], ack 2681, win 32768, length 0
10:11:10.951676 tun0, IN: IP 10.81.234.6.55421 > 172.16.3.71.443: Flags [.], ack 2683, win 32767, length 0
10:11:10.967684 tun0, IN: IP 10.81.234.6.55421 > 172.16.3.71.443: Flags [F.], seq 233, ack 2683, win 32767, length 0
10:11:10.967823 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55421: Flags [F.], seq 2683, ack 234, win 237, length 0
10:11:10.989920 tun0, IN: IP 10.81.234.6.55421 > 172.16.3.71.443: Flags [.], ack 2684, win 32767, length 0
10:11:14.149935 tun0, IN: IP 10.81.234.6.55422 > 172.16.3.71.443: Flags [S], seq 144579324, win 65535, options [mss 1340,nop,wscale 3,nop,nop,sackOK], length 0
10:11:14.149984 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55422: Flags [S.], seq 1832363907, ack 144579325, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
10:11:14.171969 tun0, IN: IP 10.81.234.6.55422 > 172.16.3.71.443: Flags [.], ack 1, win 32768, length 0
10:11:14.174074 tun0, IN: IP 10.81.234.6.55422 > 172.16.3.71.443: Flags [P.], ack 1, win 32768, length 232
10:11:14.174092 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55422: Flags [.], ack 233, win 237, length 0
10:11:14.507834 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55422: Flags [.], ack 233, win 237, length 1340
10:11:14.507846 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55422: Flags [.], ack 233, win 237, length 1340
10:11:14.507851 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55422: Flags [P.], ack 233, win 237, length 2
10:11:14.531941 tun0, IN: IP 10.81.234.6.55422 > 172.16.3.71.443: Flags [.], ack 1341, win 32768, length 0
10:11:14.532505 tun0, IN: IP 10.81.234.6.55422 > 172.16.3.71.443: Flags [.], ack 2681, win 32768, length 0
10:11:14.533439 tun0, IN: IP 10.81.234.6.55422 > 172.16.3.71.443: Flags [.], ack 2683, win 32767, length 0
10:11:14.554364 tun0, IN: IP 10.81.234.6.55422 > 172.16.3.71.443: Flags [F.], seq 233, ack 2683, win 32767, length 0
10:11:14.556015 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55422: Flags [F.], seq 2683, ack 234, win 237, length 0
10:11:14.559606 tun0, IN: IP 10.81.234.6.55423 > 172.16.3.71.443: Flags [S], seq 252560853, win 65535, options [mss 1340,nop,wscale 3,nop,nop,sackOK], length 0
10:11:14.559662 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55423: Flags [S.], seq 1926072159, ack 252560854, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
10:11:14.578396 tun0, IN: IP 10.81.234.6.55422 > 172.16.3.71.443: Flags [.], ack 2684, win 32767, length 0
10:11:14.581615 tun0, IN: IP 10.81.234.6.55423 > 172.16.3.71.443: Flags [.], ack 1, win 32768, length 0
10:11:14.583156 tun0, IN: IP 10.81.234.6.55423 > 172.16.3.71.443: Flags [P.], ack 1, win 32768, length 232
10:11:14.583179 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55423: Flags [.], ack 233, win 237, length 0
10:11:14.894134 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55423: Flags [.], ack 233, win 237, length 1340
10:11:14.894149 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55423: Flags [.], ack 233, win 237, length 1340
10:11:14.894153 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55423: Flags [P.], ack 233, win 237, length 2
10:11:14.917214 tun0, IN: IP 10.81.234.6.55423 > 172.16.3.71.443: Flags [.], ack 1341, win 32768, length 0
10:11:14.917725 tun0, IN: IP 10.81.234.6.55423 > 172.16.3.71.443: Flags [.], ack 2681, win 32768, length 0
10:11:14.918131 tun0, IN: IP 10.81.234.6.55423 > 172.16.3.71.443: Flags [.], ack 2683, win 32767, length 0
10:11:14.935762 tun0, IN: IP 10.81.234.6.55423 > 172.16.3.71.443: Flags [F.], seq 233, ack 2683, win 32767, length 0
10:11:14.935832 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55423: Flags [F.], seq 2683, ack 234, win 237, length 0
10:11:14.939750 tun0, IN: IP 10.81.234.6.55424 > 172.16.3.71.443: Flags [S], seq 4037583097, win 65535, options [mss 1340,nop,wscale 3,nop,nop,sackOK], length 0
10:11:14.939802 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55424: Flags [S.], seq 589145162, ack 4037583098, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
10:11:14.957792 tun0, IN: IP 10.81.234.6.55423 > 172.16.3.71.443: Flags [.], ack 2684, win 32767, length 0
10:11:14.961521 tun0, IN: IP 10.81.234.6.55424 > 172.16.3.71.443: Flags [.], ack 1, win 32768, length 0
10:11:14.962301 tun0, IN: IP 10.81.234.6.55424 > 172.16.3.71.443: Flags [P.], ack 1, win 32768, length 232
10:11:14.962317 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55424: Flags [.], ack 233, win 237, length 0
10:11:15.279853 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55424: Flags [.], ack 233, win 237, length 1340
10:11:15.279867 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55424: Flags [.], ack 233, win 237, length 1340
10:11:15.279872 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55424: Flags [P.], ack 233, win 237, length 2
10:11:15.303865 tun0, IN: IP 10.81.234.6.55424 > 172.16.3.71.443: Flags [.], ack 1341, win 32768, length 0
10:11:15.304235 tun0, IN: IP 10.81.234.6.55424 > 172.16.3.71.443: Flags [.], ack 2681, win 32768, length 0
10:11:15.304428 tun0, IN: IP 10.81.234.6.55424 > 172.16.3.71.443: Flags [.], ack 2683, win 32767, length 0
10:11:15.321272 tun0, IN: IP 10.81.234.6.55424 > 172.16.3.71.443: Flags [P.], ack 2683, win 32767, length 126
10:11:15.321283 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55424: Flags [.], ack 359, win 237, length 0
10:11:15.321544 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55424: Flags [P.], ack 359, win 237, length 258
10:11:15.322941 tun0, IN: IP 10.81.234.6.55424 > 172.16.3.71.443: Flags [P.], ack 2683, win 32767, length 493
10:11:15.323026 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55424: Flags [P.], ack 852, win 245, length 280
10:11:15.323147 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55424: Flags [P.], ack 852, win 245, length 31
10:11:15.323274 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55424: Flags [F.], seq 3252, ack 852, win 245, length 0
10:11:15.344147 tun0, IN: IP 10.81.234.6.55424 > 172.16.3.71.443: Flags [.], ack 2941, win 32735, length 0
10:11:15.345097 tun0, IN: IP 10.81.234.6.55424 > 172.16.3.71.443: Flags [.], ack 3221, win 32700, length 0
10:11:15.345732 tun0, IN: IP 10.81.234.6.55424 > 172.16.3.71.443: Flags [F.], seq 852, ack 3221, win 32700, length 0
10:11:15.345746 tun0, OUT: IP 172.16.3.71.443 > 10.81.234.6.55424: Flags [.], ack 853, win 245, length 0
10:11:15.346176 tun0, IN: IP 10.81.234.6.55424 > 172.16.3.71.443: Flags [R.], seq 853, ack 3252, win 0, length 0
HI MiroslavCacija,
Could you check which Certificate the website is asking ?
When using the same web site form inside ( via RDP ), it asks for certificate from my local CA, and everything works. But, when connected via VPN, it asks for Sophos certificate ( since the upgrade to v16 ). But, HTTPS scanning is disabled in VPN rule. And I cannot access the site ( any HTTPS site ) form VPN. Strange.
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
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
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:
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.
