Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 1 reply
  • Subscribers 2 subscribers
  • Views 1959 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 Remote Access: Can't load VPN client web site

colossalc
I just set up the Sophos UTM today.  Everything is working great except for the Remote Access.

My UTM server is 192.168.2.100 on default ports for internal traffic and 192.168.1.250 for external traffic using two physical NIC cards.

My version is:

Current firmware version:  9.106-17 

I followed the instructions as best I could in the "Remote Access via SSL Configuring UTM and Client" document.  There appear to be slight differences from the Version 9.0 and the 9.106-17 that I am running but it wasn't hard to follow.
  
If I load https://192.168.2.100:4444 I get to the web admin just fine.  The problem I'm having is when I attempt to load https://192.168.2.100 from any workstation to install the SSL VPN client.  I get a generic error message from either Internet Explorer or Chrome on multiple desktops telling me it can't load the page.  If I telnet to 192.168.2.100 on TCP port 443 it connects just fine.  But I can't load that URL from any web browser.

I even forwarded port 443 in my main router to the 192.168.1.250 address, tethered my notebook to Verizon cell phone and attempt to access https://mypublicip and it received the same error as if I tried accessing the UTM server in this way locally.  As such, I am unable to install the VPN client.

I enabled debug level logging and this is what is produced in the log when I load https://192.168.2.100 

2013:11:09-15:38:37 myutmsrv openvpn[6223]: MULTI: multi_create_instance called 

2013:11:09-15:38:37 myutmsrv openvpn[6223]: Re-using SSL/TLS context 

2013:11:09-15:38:37 myutmsrv openvpn[6223]: LZO compression initialized 

2013:11:09-15:38:37 myutmsrv openvpn[6223]: Control Channel MTU parms [ L:1560 D:140 EF:40 EB:0 ET:0 EL:0 ] 

2013:11:09-15:38:37 myutmsrv openvpn[6223]: Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET:0 EL:0 AF:3/1 ] 

2013:11:09-15:38:37 myutmsrv openvpn[6223]: Local Options String: 'V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-server' 

2013:11:09-15:38:37 myutmsrv openvpn[6223]: Expected Remote Options String: 'V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-client' 

2013:11:09-15:38:37 myutmsrv openvpn[6223]: Local Options hash (VER=V4): 'b695cb4a' 

2013:11:09-15:38:37 myutmsrv openvpn[6223]: Expected Remote Options hash (VER=V4): 'bc07730e' 

2013:11:09-15:38:37 myutmsrv openvpn[6223]: TCP connection established with [AF_INET]192.168.2.4:49270 (via [AF_INET]192.168.2.100:443) 

2013:11:09-15:38:37 myutmsrv openvpn[6223]: TCPv4_SERVER link local: [undef] 

2013:11:09-15:38:37 myutmsrv openvpn[6223]: TCPv4_SERVER link remote: [AF_INET]192.168.2.4:49270 

2013:11:09-15:38:37 myutmsrv openvpn[6223]: 192.168.2.4:49270 WARNING: Bad encapsulated packet length from peer (18245), which must be > 0 and 


This thread was automatically locked due to age.
Parents
  • 0
    Hi, colossalc, and welcome to the User BB!

    You will rarely, if ever, need to enable debugging.  Typically, it gives too much information, camouflaging the answer.  When analyzing a problem, the first thing to try is #1 in Rulz.

    Not necessarily "wrong" at all, but several suggestions...

    [LIST=1]
    • Use a service like FreeDNS to establish an FQDN that you can use as the hostname for your UTM (see 'DynDNS' in 'DNS') and as the target for your SSL VPN Client instead of a numeric IP.  See The Zeroeth Rule in Rulz, above.
    • On the 'Settings' tab of 'SSL VPN', change the port to something like 8883 UDP instead of 443 TCP.  That will avoid potential future conflicts and speed up the SSL VPN tunnels you create.
    • I like to change the UTM User Portal access to 2443 on the 'Advanced' tab.
    • If at all possible, bridge your modem so that the UTM can get your public IP on the External interface.  This will prevent several problems later.
    [/LIST]
    I bet you won't have any issues after making those changes.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • 0
    Hi, colossalc, and welcome to the User BB!

    You will rarely, if ever, need to enable debugging.  Typically, it gives too much information, camouflaging the answer.  When analyzing a problem, the first thing to try is #1 in Rulz.

    Not necessarily "wrong" at all, but several suggestions...

    [LIST=1]
    • Use a service like FreeDNS to establish an FQDN that you can use as the hostname for your UTM (see 'DynDNS' in 'DNS') and as the target for your SSL VPN Client instead of a numeric IP.  See The Zeroeth Rule in Rulz, above.
    • On the 'Settings' tab of 'SSL VPN', change the port to something like 8883 UDP instead of 443 TCP.  That will avoid potential future conflicts and speed up the SSL VPN tunnels you create.
    • I like to change the UTM User Portal access to 2443 on the 'Advanced' tab.
    • If at all possible, bridge your modem so that the UTM can get your public IP on the External interface.  This will prevent several problems later.
    [/LIST]
    I bet you won't have any issues after making those changes.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
No Data
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?

Unfiltered HTML