Develop Reference

WinRT application accessing external LAN via Cisco VPN

I'm developing a WinRT application. Said application will use a corporate LAN in the end to connect to available services. I suspect things will work smoothly then.
However, I'm having a bit of an issue during development.
Since I'm not on-site where the services are being developed (and where the test services have been deployed) I've been given VPN access using the Cisco Systems VPN client.
Note, that I can access the services using a browser, so I know the connection is working fine.
My issue is that the WindowsRT application doesn't seem to play nice with the VPN connection, and I get the following error when attempting to access the services:
Could not connect to net.tcp://[ServiceIp]/[ServicePath].
The connection attempt lasted for a time span of 00:00:00.0463816.
TCP error code 10013: An attempt was made to access a socket in a way
forbidden by its access permissions [ServiceIp].
AFAIK the above error is thrown when a WinRT application doesn't have the required permission (for example, to access LAN or WAN). However, out of desperation, I've tried ticking ALL the requested capabilities boxes in the package configuration, but I'd still get the same error.
Furthermore we've been given a local version of the services, and in our own LAN the application CAN connect.
Note: I still want to connect to the development machine over the VPN, because that's where all the test data is (our own machine has mock data - it was initially useful, but at this stage we need to do more specific tests).
So it seems like WinRT is throwing a hissy-fit when it's forced to use the Cisco VPN... not that I blame it - I don't like that VPN myself! :P
Still, I'd like to be able to connect to the test services. Any suggestions on how to tackle this issue?

403 Error For Web Service Call

I am using a 3rd-party tool that runs as a Microsoft Service on a Windows Server 2008 R2 machine. The machine is using a Dell SonicWall firewall. The tool has defined ports that it is listening on of which I have opened one. Using an external web tool that port is listed as open. The service has been installed and shows as running when I run services.msc.
Everything runs great on my local machine. However, when I try to query the service I get a 403 error. The following is what the query URL looks like:
https://{siteUrl}:{portNumber}/scanservice/v2/getstatus?method=jQuery111106758983342442662_1428439579840&_=1428439579841
This is an AJAX GET request coming from an ASP.NET MVC application.
The code attempts to find an open port by querying 3 ports that are the https ports for the service. The first two are ports that I have not opened on the machine. These queries time out which is what I would expect. The last port is the one I have opened on the server. I immediately get a 403 error.
Is there somewhere where I need to expressly allow that service, not just the port?

It is a case where your public IP is not whitelisted on the web service hosting server

Having problems with .NET named pipes and ambiguous exceptions

I've written a client that connects to a server via a named pipe, and it works fine with my server. However, when I try to connect to a remote server, it fails when I call Connect(), and throws "Request not supported exception", and I have no idea what that means (tried looking on msdn, didn't help).
This is the relevant piece of code. I am sure the server and the path exist, because another client (whose source I can't see, but I know it uses nxpipe) can connect to it.
NamedPipeClientStream stream = new NamedPipeClientStream(serverName, pipeName, PipeDirection.InOut);
stream.Connect(timeout);
Does anyone have any ideas what that means?
Thanks.
EDIT (SOLVED) :
You will NOT BELIEVE what the problem was. First, the guy that ordered the app forgot to ran the server app and open the pipe, so we spent hours trying to figure out what's going on, assuming the pipe is opened on the remote machine. After he remembered that he forgot to run the server app (a few days later), we still had problems. At that point I already wrote a client using .NET pipes and the native pipes using CreateFile. Turns out the guy also forgot to tell us the whole name of the pipe (weird that we got "request not supported" for invalid pipe name, though). Luckily we had an app they used earlier, which had part of that pipe name hardcoded (and part of it you still had to specify) so we used process explorer to figure out the full name of the pipe and finally connected. Now it works :|

I think this must be a Win32 IO exception (ERROR_NOT_SUPPORTED - error code 50). If so it will be coming from the RPC/SMB protocol by which named pipe communications are remoted from one machine to another. It means that one side is trying to invoke a protocol operation which is not supported by the other side.
In your context I imagine this means that the security context from which you are trying to initiate the named pipe communication is not compatible with what is supported by the other side (or conceivably even some firewall in between which has rules at the protocol level).
If both sides were Windows machines I would start by checking using NET USE whether the security context on the initiating side can establish a connection to the IPC$ share on the other side. I afraid I have no knowledge of the Libra mainframe or what difference this might make.

Named pipes only exist within the current machine. You need to use something like TCP to cross the machine boundary.
EDIT:
Correction, according to this, it is possible across a network. I must have been mistaken, and perhaps the default behavior is that access to NT AUTHORITY\NETWORK is denied.

Is it possible to write C# code as below and send email using network in different country?

Is it possible to write C# code as below and send email using mnetwork in different country?
MSExchangeWebServiceURL = mail.something.com/ews/exchange.asmx
It's a web service URL. This works great when I run the same code from home network, my friends home network anywhere around, but when I run it from my client's location in Columbia it fails.
I have a valid user name and password on that Exchange Server. Is there any configuration that I can set to achieve this?
BTW this code below works when I run it within office network and any network within any home network. I have tried it at least with five friends network in Plano, Texas. I want this code to work running from any network in another country.
My client in Columbia can connect to the web service using a browser using the same user name and password, but when I run the code above it is not able to connect to our web service.

EDIT: Based on the comments and updated post, I would wager that the client location has a proxy server or firewall that is blocking the traffic. The client probably needs to add the relevant domain to whatever "whitelist" they have.
If it works from an internal network, then the problem is most likely not the code. You need to debug it and see what error turns up when running it outside of the network. Then check the logs on the firewall and the target exchange server to see what is happening.
One possible culprit is that the DNS name is not setup outside the office network, or that the office firewall is not setup to pass traffic (or only to pass SMTP traffic) from the internet to the server in question. Another is that Exchange Web Services is not setup properly to accept requests from the outside world. That can be tested from http://www.testexchangeconnectivity.com/.
If this isn't enough for you to get there, post more info about what errors you are seeing. "It isn't working, I want it to work" kind of reminds me of the Star Trek TNG episode about the species who kept telling Geordi to "make it go".

If you are asking if the code works (which it doesn't look like you are but it's in your post) you should ask on stackoverflow. If you are wondering why it won't work from home Its likely because the edge server is not set up to relay, and if you are at home and not vpn'd into the network that's all you have access to.

You need to break this down a bit:
What's the MSExchangeWebServiceURL? I don't need to know your real URL, but is this resolvable from your home network? i.e. is it an internal DNS host (server.mycompany.local) or is it an externally-resolvable DNS host (mail.yourcompany.com)?
If it's internal, like another poster said, you'll at least need to VPN in (or replace that with the external URL).
I'm not a big C# guy, but I'm guessing it's looking for your Exchange Server hostname or FQDN, and since the type is "SMTP" it wants to establish a TCP session with your mail server. You can likely test this out by opening up your command prompt and trying to telnet <MSExchangeWebServiceURL> 25. When that works, my guess is your code will work too.

Creating a heavily restricted server discovery application in c#

I am writing you because of a new problem I need to solve, and I have now been banging my head against a wall for too long now.
Basically, I need to create an application that can take care of the following:
A user starts an app, which sends a broadcast to the subnet, and recieves a response of all servers there with their IP (and some additional info). The user can then select what server he wants to connect to.
Making it work is simple enough, with identifying the subnet, and broadcasting with UDP, and then having a different server application recieving it and sending back a response . The problem lies with these restrictions, that I need to take into consideration:
There will most likely also be clients on the server machines in the network, meaning that we can assume that the application is present on all machines. Every machine needs to have the listener running, and every machine can launch the GUI for selecting a server.
I am only allowed to add one exception to the firewall - an exception that handles both sending out the broadcasts, recieving broadcasts, sending answers and recieving answers.
I should also only be adding one Windows Service
on a server machine, the listener should run as a windows service, so the user won't notice it. Nor will the user notice, that the response is sent back to the client.
On the client machine, the user can start an application, which will notify the application to emmit the broadcast, and will get all the server responses, so the user can choose one to connect to.
Besides from the application that the user launches in order to select a server, there should be no interaction with the user whatsoever. Not even a popup, requesting the user to allow traffic trough the firewall - it should all be automatically
It needs to work on and in between Win XP, Win Vista and Win 7.
I don't know if I am putting too many constrains on myself, but I really hope that I can make the application with these requirements.
I have a few ideas - I just need to figure out how to do it:
Should i make everything into one application, that I add to the firewall exception list, so it will take care of the traffic on both the server and the client machines?
Should I add a custom exception to the firewall, allowing UDP traffic on a specific port, and then have all traffic flow trough that?
Is there a third and better option for managing that?
It is OK to have the service running on both client and server machines. But can it take care of everything for me - like it handling both the broadcast send/recieve and answer send/recieve? And is there any way to extract the information about servers on the network from a service?
I know it is a lot, but I really hope that you will be able to help me out.
let me know if I wasn't clear enough, or if you need further explanations.
I am coding in C# .Net, and I can utilize all I want from the .Net framework. As soon as I have this functionality implemented
All the best
/Sagi

The kind of peer-to-peer networking problems become simple to the point of being trivial if you designate one machine as the master server. It should have a well-known name that all sub-servers can connect to so they can publish (and withdraw) their availability. A client can then send a query request to the same server and get a list of known servers in return.
This can also solve your firewall problem, the master server could be listening on port 80.
Look into the System.Net.PeerToPeer namespace for a p2p solution supported by the framework.

Maybe a UPnP server and client may be a solution to your problem?