SSL VPN Connected but unable to use browser

Example that I can resolve / ping while connected but not browse to the same site. 

Hi Jon and welcome to the UTM Community!

Do you get any hints from the Firewall and Web Filtering logs?

Cheers - Bob

I'll pull some logs to share, at the moment I do have a client side PCAP of a failed session screenshot to share...maybe certificate related? 

I am reviewing the logs while connected and I am not seeing anything helpful. All DNS queries are successful, webfiltering action ="pass", and the FW is not blocking my queries to the UTM web host @ 10.0.155.1:4444. 

TCP Dump logs from failed https session to 10.0.155.1 while connected via VPN

HOSTNAME:~ # tcpdump -i any host 192.168.1.2 and host 10.0.155.1 -vvvv
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
21:11:08.191368 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64)
 192.168.1.2.55029 > dymanicDNS.webadmin: Flags [S], cksum 0x64ab (correct), seq 3310334379, win 65535, options [mss 1352,nop,wscale 6,nop,nop,TS val 1019531263 ecr 0,sackOK,eol], length 0
21:11:08.191547 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
dymanicDNS.webadmin > 192.168.1.2.55029: Flags [S.], cksum 0x68ed (correct), seq 3171659599, ack 3310334380, win 28960, options [mss 1460,sackOK,TS val 32713942 ecr 1019531263,nop,wscale 7], length 0
21:11:08.268954 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.2.55029 > dymanicDNS.webadmin: Flags [.], cksum 0x0076 (correct), seq 1, ack 1, win 2051, options [nop,nop,TS val 1019531360 ecr 32713942], length 0
21:11:08.270514 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 569)
192.168.1.2.55029 > dymanicDNS.webadmin: Flags [P.], cksum 0xeace (correct), seq 1:518, ack 1, win 2051, options [nop,nop,TS val 1019531360 ecr 32713942], length 517
21:11:08.270747 IP (tos 0x0, ttl 64, id 33722, offset 0, flags [DF], proto TCP (6), length 52)
dymanicDNS.webadmin > 192.168.1.2.55029: Flags [.], cksum 0x0575 (correct), seq 1, ack 518, win 235, options [nop,nop,TS val 32713962 ecr 1019531360], length 0
21:11:08.321551 IP (tos 0x0, ttl 64, id 33723, offset 0, flags [DF], proto TCP (6), length 1392)
dymanicDNS.webadmin > 192.168.1.2.55029: Flags [.], cksum 0x65ad (correct), seq 1:1341, ack 518, win 235, options [nop,nop,TS val 32713974 ecr 1019531360], length 1340
21:11:08.321579 IP (tos 0x0, ttl 64, id 33724, offset 0, flags [DF], proto TCP (6), length 821)
dymanicDNS.webadmin > 192.168.1.2.55029: Flags [P.], cksum 0x64db (correct), seq 1341:2110, ack 518, win 235, options [nop,nop,TS val 32713974 ecr 1019531360], length 769
21:11:08.399513 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64)
192.168.1.2.55029 > dymanicDNS.webadmin: Flags [.], cksum 0xe194 (correct), seq 518, ack 1, win 2051, options [nop,nop,TS val 1019531487 ecr 32713962,nop,nop,sack 1 {1341:2110}], length 0
21:11:08.417872 IP (tos 0x0, ttl 64, id 33725, offset 0, flags [DF], proto TCP (6), length 1392)
dymanicDNS.webadmin > 192.168.1.2.55029: Flags [.], cksum 0x6515 (correct), seq 1:1341, ack 518, win 235, options [nop,nop,TS val 32713999 ecr 1019531487], length 1340
21:11:08.697946 IP (tos 0x0, ttl 64, id 33726, offset 0, flags [DF], proto TCP (6), length 1392)
dymanicDNS.webadmin > 192.168.1.2.55029: Flags [.], cksum 0x64cf (correct), seq 1:1341, ack 518, win 235, options [nop,nop,TS val 32714069 ecr 1019531487], length 1340
21:11:09.257967 IP (tos 0x0, ttl 64, id 33727, offset 0, flags [DF], proto TCP (6), length 1392)
dymanicDNS.webadmin > 192.168.1.2.55029: Flags [.], cksum 0x6443 (correct), seq 1:1341, ack 518, win 235, options [nop,nop,TS val 32714209 ecr 1019531487], length 1340
21:11:10.381967 IP (tos 0x0, ttl 64, id 33728, offset 0, flags [DF], proto TCP (6), length 1392)
dymanicDNS.webadmin > 192.168.1.2.55029: Flags [.], cksum 0x632a (correct), seq 1:1341, ack 518, win 235, options [nop,nop,TS val 32714490 ecr 1019531487], length 1340
21:11:12.629974 IP (tos 0x0, ttl 64, id 33729, offset 0, flags [DF], proto TCP (6), length 1392)
dymanicDNS.webadmin > 192.168.1.2.55029: Flags [.], cksum 0x60f8 (correct), seq 1:1341, ack 518, win 235, options [nop,nop,TS val 32715052 ecr 1019531487], length 1340
21:11:17.125895 IP (tos 0x0, ttl 64, id 33730, offset 0, flags [DF], proto TCP (6), length 1392)
dymanicDNS.webadmin > 192.168.1.2.55029: Flags [.], cksum 0x5c94 (correct), seq 1:1341, ack 518, win 235, options [nop,nop,TS val 32716176 ecr 1019531487], length 1340
21:11:26.118004 IP (tos 0x0, ttl 64, id 33731, offset 0, flags [DF], proto TCP (6), length 1392)
dymanicDNS.webadmin > 192.168.1.2.55029: Flags [.], cksum 0x53cc (correct), seq 1:1341, ack 518, win 235, options [nop,nop,TS val 32718424 ecr 1019531487], length 1340
21:11:38.288345 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
192.168.1.2.55029 > dymanicDNS.webadmin: Flags [R.], cksum 0x7372 (correct), seq 518, ack 1, win 2051, length 0

Have you checked the routing table in your newly-rebuilt laptop?  That's my guess as to not being able to reach yahoo.com.

The certificate problem might be resolved by using a different browser.

Any luck with either of those thoughts?

Cheers - Bob

I rebuilt my system and restored config hoping to resolve...it did not.

I get the same results with Safari (2nd browser) and the default route points to the correct GW. 

I did discover that while connected to the VPN I am able to browse to http://neverssl.com Based on this finding and previous PCAP I believe there is an issue with the browser establishing a TLS connection while connected via SSL VPN, not sure how to proceed with additional troubleshooting. 

I have all my logs now fed into Splunk and can confirm the only occasional denies I see are what I think to be default drops...not 100% if related to this issue. Also not clear on best approach to troubleshoot/test this theory if it makes sense...screenshot below. 

I think we're making this into a more-complex problem than it is, Jon.  Let's go back to basics.

Connected to the SSL VPN, do a route print from the command line and show us the IPv4 Route Table.   If you're on a Mac, I don't know how to do this.

Show us the DNS setup in 'Remote Access >> Advanced' and the Edit of the SSL VPN Profile you're using.

Cheers - Bob

Sounds good - 

While connected via SSL VPN:

juans-MacBook-Pro:~ juan$ netstat -nr

Routing tables

Internet:

Destination        Gateway            Flags        Refs      Use   Netif Expire

0/1                192.168.1.1        UGSc           64        0  utun10       

default            172.20.10.1        UGSc            0        0     en1       

76.122.63.96/32    172.20.10.1        UGSc            1        0     en1       

127                127.0.0.1          UCS             0        0     lo0       

127.0.0.1          127.0.0.1          UH              2      292     lo0       

128.0/1            192.168.1.1        UGSc            5        0  utun10       

169.254            link#8             UCS             1        0     en1      !

172.20.10/28       link#8             UCS             1        0     en1      !

172.20.10.1/32     link#8             UCS             1        0     en1      !

172.20.10.1        76:b5:87:c2:bb:64  UHLWIir         5       59     en1   1127

172.20.10.2/32     link#8             UCS             1        0     en1      !

172.20.10.2        24:a2:e1:f3:c7:f2  UHLWI           0        2     lo0       

172.20.10.15       ff:ff:ff:ff:ff:ff  UHLWbI          0        6     en1      !

192.168.1          192.168.1.3        UGSc           18        0  utun10       

192.168.1.3        192.168.1.3        UH              2        0  utun10       

224.0.0/4          link#16            UmCS            2        0  utun10       

224.0.0/4          link#8             UmCSI           2        0     en1      !

224.0.0.251        1:0:5e:0:0:fb      UHmLWI          0        0     en1       

224.0.0.251        link#16            UHmW3I          0        0  utun10   3542

239.255.255.250    1:0:5e:7f:ff:fa    UHmLWI          0        4     en1       

239.255.255.250    link#16            UHmW3I          0        4  utun10   3542

255.255.255.255/32 link#16            UCS             0        0  utun10       

255.255.255.255/32 link#8             UCSI            0        0     en1      !

First, try de-selecting compression and replacing "Any IPv4" in the Profile with "Internet IPv4" and the "(Network)" objects of your LAN Interface(s).  Any better luck now?

If not, confirm that the "VPN Pool (SSL)"=192.168.1.0/24 does not overlap with any other IP remote or local.

Cheers - Bob

First, try de-selecting compression and replacing "Any IPv4" in the Profile with "Internet IPv4" and the "(Network)" objects of your LAN Interface(s).  Any better luck now?

If not, confirm that the "VPN Pool (SSL)"=192.168.1.0/24 does not overlap with any other IP remote or local.

Cheers - Bob

Thanks Bob...so I made those changes and it looks like I am getting the same behavior.

Does doing #1 in Rulz (last updated 2019-04-17) give you any clues, Jon?

Cheers - Bob

Good idea...I'll keep poking around for other clues as well as reviewing additional rulz. I do have all syslog messages being sent to Splunk and I don't see any denies/blocks/etc. from my most recent test. FWIW I am testing from my mobile as a hotspot...don't see why that would matter as it's worked in the past but it is another datapoint. 

Bob - It doesn't make much sense to me but when I connected from a Hotel Wifi this evening everything works as expected...disconnected and confirmed the issue above still exists from my cell phone hotspot. I think we can mark this issue as resolved, thanks for all the help!