Problem with NORD-VPN-Client and Suricata
-
First, I am a noob and not a native english speaking person. Bummer.
I am on suricata 4.1.4_8 at default settings in LEGACY MODE on the LAN-Interface on pfsense 2.4.4-RELEASE-p3.
My problem, lately my VM @home, which is using the NORD-VPN-Client on Windows, looses the connection to that VPN.
PfSense is using NAT and there are no forwards to that VM.
Disabling Suricata solves the problem with the VPN-Client in that VM!So I probably would like to disable suricata for that VM only, because all Internet Connections should go through the Windows-VPN-Client on that machine anyway.
How can I achieve that via the GUI?
Here is an example of an alert I really don't need (I think). Destination is the VM (and why is the port 0)...:
-
@Bob-Dig said in Problem with NORD-VPN-Client and Suricata:
First, I am a noob and not a native english speaking person. Bummer.
I am on suricata 4.1.4_8 at default settings in LEGACY MODE on the LAN-Interface on pfsense 2.4.4-RELEASE-p3.
My problem, lately my VM @home, which is using the NORD-VPN-Client on Windows, looses the connection to that VPN.
PfSense is using NAT and there are no forwards to that VM.
Disabling Suricata solves the problem with the VPN-Client in that VM!So I probably would like to disable suricata for that VM only, because all Internet Connections should go through the Windows-VPN-Client on that machine anyway.
How can I achieve that via the GUI?
Here is an example of an alert I really don't need (I think). Destination is the VM (and why is the port 0)...:
The port is 0 because that is a generic decoder alert. It is probably getting triggered by the way the VPN client is doing things. Most likely a false positive. Why don't you just disable that rule? Click the red X under the GID:SID column to disable the rule.
If you want to prevent any traffic for that VM IP (I assume 192.168.1.39 is the VM) from getting inspected by Suricata, then you will need to create a couple of PASS rules in the Custom Rules section accessible on the RULES tab. You would have one rule where that VM IP is the Source IP and another where that VM is the Destination IP. Here is a link to the Suricata documentation on PASS rules: https://suricata.readthedocs.io/en/suricata-4.1.2/performance/ignoring-traffic.html#pass-rules.
To access the Custom Rules section, go to the RULES tab and select "Custom Rules" in the Category drop-down on that tab. Type or paste in your custom rules, then click Save.
-
@bmeeks Thank you for your reply.
Rules like this?
pass ip 192.168.1.39 any <> any any
pass any any <> ip 192.168.1.39 anyI will give it a try, thanks again.
-
@Bob-Dig said in Problem with NORD-VPN-Client and Suricata:
@bmeeks Thank you for your reply.
Rules like this?
pass ip 192.168.1.39 any <> any any
pass any any <> ip 192.168.1.39 anyI will give it a try, thanks again.
Those rules should suffice, but there is a typo in your second rule. The protocol (in this case, "ip") always goes immediately after the action. So the second rule needs to read this way:
pass ip any any <> 192.168.1.39 any
-
@bmeeks Thanks again, Bill. Seems to work fine now!
-
@Bob-Dig said in Problem with NORD-VPN-Client and Suricata:
@bmeeks Thanks again, Bill. Seems to work fine now!
Glad it works for you. PASS rules are evaluated first, and if traffic matches a PASS rule, no further inspection is done by Suricata. The packet is unconditionally allowed if it matches a PASS rule. So be careful with those kinds of rules because it is easy to unintentionally render Suricata "toothless" if you were, for example, to construct a PASS rule that was too broad in which IP addresses it permitted.
-
I saw this today
although I had made exceptions
Did I missed something?
-
Also Suricata randomly(?) stops. But it is the first time I installed the Snort free Registered User rules (-29141)...
-
@Bob-Dig said in Problem with NORD-VPN-Client and Suricata:
I saw this today
although I had made exceptions
Did I missed something?
I am going to assume those 192.168.1.x addresses are from a locally-attached subnet and thus form your LAN or another local network. If true, they were not blocked because of the default Pass List.
With Legacy Mode blocking (which I see you are using), you really can't use PASS rules like that. That's because the traffic (even when passed) still routes through the logging plugins and the custom blocking module used on pfSense registers as a logging plugin. So it will see the traffic and potentially can block.
To do what you want, you need to switch your Legacy Mode option to "Block DROPS Only". That's a checkbox in the Blocking Configuration section of the INTERFACE SETTINGS tab. Then you need to implement a SID MGMT tab strategy to change the rules you want to block to DROP and leave others as ALERT. In that mode, the custom blocking module will only block for rules which have DROP as the rule action.
-
@Bob-Dig said in Problem with NORD-VPN-Client and Suricata:
Also Suricata randomly(?) stops. But it is the first time I installed the Snort free Registered User rules (-29141)...
Check the system log and the
suricata.logfile. Thesuricata.logfile can be viewed on the LOGS VIEW tab. There should be something in one of those logs to offer a hint. Don't restart Suricata until you check the log files. Thesuricata.logfile is overwritten each time Suricata starts.Make sure you do NOT use the Service Watchdog package with Suricata (nor with Snort). That package does not understand how to properly monitor the IDS/IPS packages on multiple interfaces and it does not correctly account for automatic restarts performed by the IDS/IPS packages upon rules updates. In short, just DO NOT use Service Watchdog with Suricata or Snort. You may not be doing that, but I mention it because I've run across folks doing that many times in the past.
-
@bmeeks said in Problem with NORD-VPN-Client and Suricata:
I am going to assume those 192.168.1.x addresses are from a locally-attached subnet and thus form your LAN or another local network. If true, there were not blocked because of the default Pass List.
With Legacy Mode blocking (which I see you are using), you really can't use PASS rules like that. That's because the traffic (even when passed) still routes through the logging plugins and the custom blocking module used on pfSense registers as a logging plugin. So it will see the traffic and potentially can block.
To do what you want, you need to switch your Legacy Mode option to "Block DROPS Only". That's a checkbox in the Blocking Configuration section of the INTERFACE SETTINGS tab. Then you need to implement a SID MGMT tab strategy to change the rules you want to block to DROP and leave others as ALERT. In that mode, the custom blocking module will only block for rules which have DROP as the rule action.
Ok, that looks to complicate for me.
Don't restart Suricata until you check the log files. The suricata.log file is overwritten each time >Suricata starts.
I will have a closer look next time, thanks as always.
-
@Bob-Dig said in Problem with NORD-VPN-Client and Suricata:
Ok, that looks to complicate for me.
It's not that hard, but in your case an easier solution would be to disable those ET User-Agent rules. Or at least disable those particular ones triggering on the Microsoft traffic. Lots of those rule categories are going to generate false positives. This is particularly true in a home network. And even with most small business networks those kinds of rules serve to generate more trouble than protection.
Look at the alerts you posted in the screen capture. They are just from normal Microsoft telemetry data the OS sends home to the mothership. All in all it's harmless. You can attempt to block it, but it's going to cause issues and likely break stuff in strange ways within Windows.
