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?