Windows file sharing over l2tp ipsec vpn

Does doing #1 in Rulz give you any clues?

Cheers - Bob

Nothing in the firewall log.  There were a number of entries in the ITP log.  I've made the adjustments for those. Won't have access to a fast connection until next weekend. 

We do have voip here too, but I did see any exceptions or not including the voip devices in ITP.  I suspect we have no issues because all connections are outbound initiated. As I understand it, calls received come in on those outbound connections that remain open.

Thanks for the suggestion.  Will report back if it solves the problem.

Haven't had a chance to thoroughly test out the flood bypass works --- those were the entries in the ips log.

I did discover something else.  When copying files from a local pc to the one connected via vpn (or vice versa), running top via ssh, snort has pretty high cpu usage.

Spent a few hours trying all sorts of ways to try to add vpn traffic as an exception but to no avail.  Tried bypassing traffic from vpn user going to local lan, scope windows networking.  Tried countless other combinations.

Any hints or suggestions?

Is there a snort log that I can see what traffic it's scanning, that would give insight how to add it to the exception list.

Thanks!

I don't know of a way to monitor what Snort is scanning.  Can we see a picture of the Exception that's not working?

Cheers - Bob

Bob,

I've tried all sorts of variations including using network address, network network (x.y.z.w/24) objects and more.

Jsolo (user network) is private IP assigned to the vpn user when logged into the L2TP/ipsec vpn. Internal_port2 is the local lan network (10.10.1.0/24).  I've played around with and operators too.  Makes no difference.  As soon as a file copy from a network share is initiated snort moves to the top of the top list.

Under Global, I've even tried adding a local network that's not in use (vlan used during testing other things).

I know for sure IPS is involved because there's no snort task when global is switched off.

Try the following in the Exception:

1. Delete "Using these services"
2. Put "Jsolo (user network)" and "Internal_port2" both into both "Coming from ..." and "Going to"
3. Change the logical operator to "and"
4. In 'Skip these checks', also select TCP and UDP 'Flood Protection'

Any better luck now?

Cheers - Bob

Negative.

No change.

Hopefully, you won't need to start doing packet captures...

Have you assigned at least one WINS server in 'Remote Access >> Advanced'?

Cheers - Bob

Just 0.0.0.0 for WINS server in remote access/advanced.  I don't have a WINS server on the network.

I do want to also point out, even if I put in a bogus local network under intrusion prevention/global, I still get this issue.  Considering the bogus local network, it shouldn't be monitoring anything that doesn't match that network setting, right?  This might explain why the exceptions are being ignored¿?

Ahh,.. The plot thickens.

I decided to forgo fighting with IPS/snort and just turned it off for now.

Had access to a somewhat reasonably fast connection using the local college wifi.  ~45-50 mbps down, 80 mbps up.

Running speed tests while connected to the L2TP/ipsec vpn I got downloads around 40mbps, uploads ~70 mbps.  This is using various speed test sites. I think these are very respectable relative speeds obtained without the vpn.

Where it fell on its face with with windows shares - ~15-20 mbps down, ~30 mbps up.  These speeds are from the perspective of the vpn client pc.  All  pc's used for testing behind the utm are hardwired gigabit along with the wan pipe (gigabit fiber) to the utm. 

While performing transfers there was barely any cpu usage on the utm box. I have a feeling there is some kind of mtu mismatch or other such packet setting.  The only setting enabled in the firewall between the l2tp/ipsec vpn and local lan is to allow access to all ports from the vpn to the local lan.  As I type this, I wonder, maybe I need to add the lan as a source too.........

Any ideas anyone?

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

Cheers - Bob

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).

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).

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.

@sachingurung

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

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

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.