Guest User!

You are not Sophos Staff.

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

I have issue connecting to lan site, the vpn connection established and the internet also work fine, but am not able to ping any lan network.

here is the log from vpn client.

10:17:40.950 -- ----- OpenVPN Start -----

10:17:40.950 -- EVENT: CORE_THREAD_ACTIVE

10:17:40.952 -- OpenVPN core 3.git:released:662eae9a:Release android arm64 64-bit PT_PROXY

10:17:40.952 -- Frame=512/2048/512 mssfix-ctrl=1250

10:17:40.956 -- UNUSED OPTIONS
3 [explicit-exit-notify]
4 [resolv-retry] [infinite]
5 [nobind]
6 [persist-key]
7 [persist-tun]
15 [route-delay] [4]
16 [verb] [3]

10:17:40.958 -- EVENT: RESOLVE

10:17:41.172 -- Contacting 93.112.145.70:8443 via UDP

10:17:41.173 -- EVENT: WAIT

10:17:41.180 -- Connecting to [testvpn20.hopto.org]:8443 (93.112.145.70) via UDPv4

10:17:41.209 -- EVENT: CONNECTING

10:17:41.211 -- Tunnel Options:V4,dev-type tun,link-mtu 1570,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA256,keysize 128,key-method 2,tls-client

10:17:41.211 -- Creds: Username/Password

10:17:41.212 -- Peer Info:
IV_VER=3.git:released:662eae9a:Release
IV_PLAT=android
IV_NCP=2
IV_TCPNL=1
IV_PROTO=2
IV_LZO_STUB=1
IV_COMP_STUB=1
IV_COMP_STUBv2=1
IV_GUI_VER=net.openvpn.connect.android_3.2.4-5891
IV_SSO=openurl


10:17:41.556 -- VERIFY OK: depth=0, /C=NA/ST=NA/L=NA/O=NA/OU=NA/CN=Appliance_Certificate_K4iDxJSR2smjQd5/emailAddress=na@example.com

10:17:41.854 -- SSL Handshake: CN=Appliance_Certificate_K4iDxJSR2smjQd5, TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

10:17:41.854 -- Session is ACTIVE

10:17:41.855 -- EVENT: GET_CONFIG

10:17:41.857 -- Sending PUSH_REQUEST to server...

10:17:42.104 -- OPTIONS:
0 [route-gateway] [10.81.234.5]
1 [sndbuf] [0]
2 [rcvbuf] [0]
3 [sndbuf] [0]
4 [rcvbuf] [0]
5 [ping] [45]
6 [ping-restart] [180]
7 [redirect-gateway] [def1]
8 [topology] [subnet]
9 [route] [remote_host] [255.255.255.255] [net_gateway]
10 [inactive] [900] [7680]
11 [dhcp-option] [DNS] [8.8.8.8]
12 [ifconfig] [10.81.234.6] [255.255.255.0]


10:17:42.104 -- PROTOCOL OPTIONS:
  cipher: AES-128-CBC
  digest: SHA256
  compress: LZO_STUB
  peer ID: -1

10:17:42.105 -- EVENT: ASSIGN_IP

10:17:42.114 -- exception parsing IPv4 route: [route] [remote_host] [255.255.255.255] [net_gateway]  : addr_pair_mask_parse_error: AddrMaskPair parse error 'route': remote_host/255.255.255.255 : ip_exception: error parsing route IP address 'remote_host' : Invalid argument

10:17:42.138 -- Connected via tun

10:17:42.139 -- LZO-ASYM init swap=0 asym=1

10:17:42.140 -- Comp-stub init swap=0




This thread was automatically locked due to age.
Parents Reply
  • FormerMember
    +1 FormerMember in reply to ferozsyed

    Alright, This is because the SSL VPN network is unknown to the Local machines hence they forward traffic to the gateway. In this case, You're getting response form the machines which have XG as a gateway but not UTM because the response packets must be getting forwarded to UTM instead of XG

    To rectify this, You can add a NAT rule for VPN to LAN traffic and keep 'Translated source (SNAT)' to MASQ. Verify once again after making these changes.



Children
  • working well... after applying source nat  vpn to lan

    Could please describe the issue.

  • FormerMember
    0 FormerMember in reply to ferozsyed

    Great.!,

    By adding 'MASQ' in SNAT in the NAT Rule, You're NATTing the traffic going to the internal network (From VPN) with the IP address of that LAN port on XG.

    Systems in your network which had UTM as a gateway, Didn't know about the SSL VPN network. The basic behavior of the machine is to forward traffic of unknown networks to the network gateway. 

    None of the end machines have routes for the SSL VPN network that is configured on XG. So end machines would send the traffic (response packets) to its gateway. 

    In your scenario, Systems that had XG as a gateway, all of those were getting pinged. On the other hand, systems that had UTM as a gateway must be sending their traffic (response packets) to the UTM instead of XG and because of this communication didn't work. 

  • Understood...Thank you for your clear explanation and thanks for resolving the issue.