Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 2 subscribers
  • Views 8170 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSL VPN Connected but unable to use browser

Jon Engle

Running Sophos UTM (9.601-5) successfully for a couple years and recently had to rebuild my laptop. After rebuild I pulled openvpn config from user portal and imported to viscosity client. I am able to successfully connect and can ping external sites (8.8.8.8) when connected, can SSH to the UTM device itself, but...I cannot open anything with a web-browser (Chrome/Safari), including the Sophos dashboard. I have looked at my logs and can see successful DNS resolution, nothing obvious in FW logs, have tried toggling IPS and web-proxy into off position without any success...anything obvious I might be missing here?  



This thread was automatically locked due to age.
Parents
  • 0

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

     

  • 0 in reply to Jon Engle

    Hi Jon and welcome to the UTM Community!

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

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to Jon Engle

    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

  • 0 in reply to Jon Engle

    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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    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. 

  • 0 in reply to Jon Engle

    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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    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      !

     

  • 0 in reply to Jon Engle

    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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

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

  • 0 in reply to Jon Engle

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

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    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. 

  • 0 in reply to Jon Engle

    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! 

Reply
  • 0 in reply to Jon Engle

    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! 

Children
No Data
Unfiltered HTML