remote call script by icmp: fail tcp socket

This topic contains 4 replies, has 2 voices, and was last updated by Profile photo of Станислав Шумейко Станислав Шумейко 1 year, 9 months ago.

  • Author
    Posts
  • #22849

    Hello guys, need help.
    I have a simple code in script and this script works correctly when I run locally :

    $server = "srv"
    $portToCheck = '1433'
    Test-NetConnection -ComputerName $server -Port $portToCheck

    similar :

    $server = "srv"
    $portToCheck = '1433'
    New-Object System.Net.Sockets.TCPClient -ArgumentList $server,$portToCheck

    But when I try to call this script remotely by icmp I receive an error :
    WARNING: TCP connect to srv:1433 failed false Exception calling ".ctor" with "2" argument(s): "An attempt was made to access a socket in a way forbidden by its access permissions 192.168.12.145:1433"
    end I have notify in event:

    The Windows Filtering Platform has blocked a connection.
    
    Application Information:
    	Process ID:		2524
    	Application Name:	\device\harddiskvolume2\windows\syswow64\windowspowershell\v1.0\powershell.exe
    
    Network Information:
    	Direction:		Outbound
    	Source Address:		192.168.12.183
    	Source Port:		54636
    	Destination Address:	192.168.12.145
    	Destination Port:		1433
    	Protocol:		6
    
    Filter Information:
    	Filter Run-Time ID:	66927
    	Layer Name:		Connect
    	Layer Run-Time ID:	48
    

    So, I had blocked package. Have you any ideas how to get around the problem? I would like to resolve this issue only with help PowerShell solution without writing filter by C++ for ALE WFP
    I tried to use in script body: Invoke-command , -asjob
    Now I've created job in task scheduler and ICMP call to start job. Result (true or false) write to txt file after that I've got content. But it's crutch and isn't true way.

    Additionally: this situation catch only on servers with Server 2012R2 (WMF4), on Server 2008r2 all works without any problems.

  • #22879
    Profile photo of Don Jones
    Don Jones
    Keymaster

    Well, you didn't block "package," you have a blockage on outbound port access by PowerShell.exe. The filtering platform is managed by Windows Firewall; have you confirmed that the machines in question are allowing outbound access via the Firewall? You shouldn't need to write a filter – you should just need to make sure the firewall is allowing outbound access. The default outbound rules do change from version to version in Windows, and obviously organizational policy (GPO) can set rules.

    You probably just need to create a firewall rule for that port and process. And yes, you can do that in PowerShell in Win2012R2.

  • #22895

    Thank you for answer.
    But as I've written if I run script local – all works fine, Also I've tried to create outbound rules for powershell.exe process and ports, I've tried to write a code by c# , compile, create rule for .exe – any changes. Only when I stopped Base Filtering Engine service and all dependent services packets didn't block. Yep I know, that why WF doesn't work.
    So Now I got confuse.

    Relation graf:

    Doc station (ICMP request) —————> Server with hosted script (SRV) ————-> DB Server

    ps1 running from SRV in case run local
    In case run ICMP request to SRV for start ps1 – catch error: ctor......

  • #22896
    Profile photo of Don Jones
    Don Jones
    Keymaster

    So, running a script remotely can sometimes create delegation problems for your credentials. It's possible that the remote machine, when running its script, is not able to present credentials proving an authenticated user is attempting to open the port. I'm not clear on how you're using PowerShell to send an ICMP request to a server and cause a script to be run, I guess.

  • #22949

    I'm sorry for delay.

    And I a gross mistake in the description my case. Of course I use and sent no ICMP request, but SNMP, When I wrote this topic I was careless ^(
    I sent requests by Paessler SNMP Tester (http://www.paessler.com/tools/snmptester).

You must be logged in to reply to this topic.