Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 16 replies
  • Subscribers 3 subscribers
  • Views 30733 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

Windows file sharing over l2tp ipsec vpn

Jay Jay

I'm trying to connect remotely to a local pc to access its files.

Remote connection to utm vpn server establishes successfully.  I can see the shared folders of the pc behind the UTM.

However, when I try to copy a remote file (behind the utm) to the vpn client machine it'll start to transfer but then stall out.  Bandwidth is not an issue.  UTM is connected to gigabit capable internet, and vpn client is comcast 200+ mbps capable.  Both of these 'pipes' likely exceed the cpu encryption capabilities of the pc running utm (i5 5250u).

Here's the firewall rule I established which I believe should allow full traversal in both directions.

Internal network is the local lan behind the utm (10.10.1.0/24)

jsolo (usernetwork) is the ip (10.242.3.2 typically) assigned to the l2tp/ipsec user account when logging into this vpn.

I'm thinking perhaps instead of referencing the user account, the entire 10.242.3.0/24 network should be allowed?

Perhaps I'm overlooking some other requirements for file sharing?  Maybe l2tp w/ ipsec is not the best vpn service for this?

I did have to disable the firewall on the pc behind the utm to even be able to ping it. Once I get the utm settings figured out, i'll add the 10.242.3.0/24 as an allowed remote network.

Thoughts, suggestions please.  I'd really like to get this working.

Thanks!



This thread was automatically locked due to age.
  • 0 in reply to Jay Jay

    Check the MTUs.  There are some ISPs that mistakenly set MTUs at 576.

    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

    The ISP provided gateway was set at mtu 1500 bytes.  This mirrors the setting on the UTM's wan and lan ports.  When connected through l2tp/ipsec, windows negotiates a mtu of 1380.  I'll make that change to both the gateway and utm wan ports (lan too?).

    The gateway is in a pseudo passthrough mode.  It passes the public ip to the utm but isn't a true bridge mode as there's still some NATting going on.  Gateway's NAT table is still in use based on the dynamic number of sessions available vs total.  Constantly changing.  This is about as good as it's going to get.. Arris BGW210-700.

    I did some more testing last night using my cell phone hotspot.  Adjusting mtu to 1472 on the gateway and utm's wan & land ports improved both download and upload to ~8mbps, cricket's throttle cap limit.  I'll have access to a cable connection later today to test further with real speeds.  I'm still able to hit the isp's gigabit speeds with local lan clients (not through vpn), also, client-client speeds on the local lan are unaffected (didn't expect them to be).

  • +1 in reply to Jay Jay

    Finally some good news to report. The cable connection I used for testing had a dl/ul speed of 175/25 mbps respectively.  I need a faster connection to find my utm box's actual limits given gigabit internet speeds in both directions.  Establishing the l2tp/ipsec tunnel on the local lan to the utm (a sort of loopback mode?) achieves speeds around 300-350 mbps in either direction with ips off and about 250 mbps in either direction with ips on.  These numbers are from speedtest.net and dslreports speed test.

    Setting the isp gateway, utm WAN and LAN MTU all to 1472 allowed for full bandwidth of the above cable connection when connecting over L2TP/ipsec even with IPS enabled (albeit utm cpu usage was high).  Files copied over from remote windows shares at ~20 MB/s which equates to ~160mbps.  Figuring overhead this reasonably good speed.  This correlates given the above max local speeds achieved (250-350 mbps).

    I played around with setting the above 3 MTU's at various combinations of 1472 and 1500 bytes.  It seems setting any of those to 1500 would induce slower throughput so I left them all at 1472. I suppose this makes some sense.  If any are at the higher value then fragmentation results.

    Performance with SSL vpn (openvpn) was much slower, ~40 mbps.  I think it's an mtu issue also but don't see any place to adjust it in the UTM or custom settings.  Changes can be made to the client config file so i'll try making some tweaks there.

     

     

  • 0 in reply to Jay Jay

    @

    Any thoughts on how to track snort/ips to figure out why it's ignoring the IPS exeption?

  • 0 in reply to Jay Jay

    Please start a new thread with an appropriate title and how relevant lines from the Intrusion Prevention log along with the Edit of the Exception that should have applied.

    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

    Wanted to update this thread while the information was still fresh.

    My internet is FTTH. ISP equipment consists of 2 pieces of hardware.  The ONT which converts fiber to ethernet and residential gateway (RGW) which authenticates the connection and provides IP passthrough or acts as a router for the lan depending on how its configured.

    Previously the RGW was used in passthrough mode to establish connectivity.  Dropping the MTU on all interfaces fixed the throughput issue.

    More recently the RGW is no longer inline between UTM and the ONT.  Private message for more info or review the bypass threads on dslreports/uverse section.  Now the ONT is connected directly to the WAN interface of the UTM.  MTU on both wan/lan interfaces in utm has been reset back to 1500.  No speed issues at all with either openvpn or l2tp/ipsec methods.

    I'd surmise that because of the way the RGW handled packets in passthrough mode, some additional bytes were added to the frames, thus reducing the max packet payload size.  Not much information is available on how the passthrough mode works, but it does appear to be a pseudo1:1 NAT mode of sorts on the RGW. This is evidenced by the fact that the RGW's NAT table is constantly changing with just a single connected device - the UTM.  If it were a true bridge then no NATting would be taking place. In other words it was passing the public ip but there was still double natting going.  The gateway's IP is also the 2nd hop in any traceroute.

    Quite the obscure issue to resolve.

Unfiltered HTML