How to prevent WCF service to register non 127.0.0.1 adresses? - wcf

When registering a WCF Service I get
HTTP could not register URL http://+:8080/ because TCP port 8080 is being used by another application
Looking at the used ports with
netstat -an | grep 8080
I can see that TCP 127.0.0.2:8080 is used (I'm using ssh to tunnel from 127.0.0.2:8080 to a remote service).
Probably the WCF service tries not only to register at 127.0.0.1 and the network ips but also on 127.0.0.2.
How can I configure the WCF service to not try to listen to 127.0.0.2:8080 but only to 127.0.0.1:8080 and the network ip adresses? Or can I configure the init process that adresses where the service can not be registered are just ignored?

whole 127/8 block signifies localhost. so both 127.0.0.1 and 127.0.0.2 point to local machine. which implies 127.0.0.1:8080 is same as specifying 127.0.0.2:8080.
they both point to same service which in this case is ssh tunnel . hence WCF fails to register
solution is to change port number.

Related

Consul - register external service provided via SSL

The Consul documentation shows how to register external services, but the examples shown are always targeting port 80 (and 443 only for health checks, which is even more peculiar) - example: https://learn.hashicorp.com/tutorials/consul/service-registration-external-services
If you register a service for port 443, a using service having it as upstream in fact gets a port opened from its local Envoy, but one cannot access this port - curl always complains about wrong protocol version. In contrast, if one registers a service for port 80, plain HTTP access works as expected.
Does anybody have an idea how an https based service can be provided as external service?

How does SSH dynamic forward (-D) function under the hood?

How does SSH dynamic forward (-D) function under the hood?
I understand that SSH dynamic forward opens a SOCSK4 proxy on the local host, and that each connection to the SOCK4 proxy is forwarded over the SSH tunnel to the remote destination.
Does SSH intercept the connections to the SOCKS4 proxy? I mean, it cannot be a "normal" SOCKS4 proxy, because then it would directly proxy the connections to the remote hosts.
Furthermore, how does SSH handle responses from the remote hosts, i.e., how does it transfer them back over the SSH tunnel to the recipients on the local host?
When the -D flag is given, the SSH client will start a built-in SOCKS4/5 proxy. (note: "SOCKS", not "SOCK").
-D [bind_address:]port
Specifies a local “dynamic” application-level port forwarding. This works by allocating a socket to listen to port on the local side, optionally bound to the specified bind_address. Whenever a connection is made to this port, the connection is forwarded over the secure channel, and the application protocol is then used to determine where to connect to from the remote machine. Currently the SOCKS4 and SOCKS5 protocols are supported, and ssh will act as a SOCKS server.
When another application wishes to connect to a proxied service, they will establish a connection via this SOCKS server. The SOCKS protocol is a little bit of negotiation that occurs at the beginning of a connection, something like this: (inspired by the wiki page)
ssh -D 1234 user#remote is execute, the SSH client starts a SOCKS proxy server listening on port 1234.
A local application wishes to communicate with a service via the SOCKS proxy, so connects to port 1234.
The SOCKS client asks for a connection to a particular IP address and port - e.g: 66.102.7.99, port 4321.
The SOCKS server, in this case the SSH client, will negotiate to establish this onward connection with it's server (remote, from above). This may fail.
The SOCKS serve will respond to the client with success / failure information.
If successful, all data passed through this socket will now be forwarded appropriately:
From the local application, to the SSH server (remote), and then onto 66.102.7.99.
From 66.102.7.99 to the SSH server (remote), and then onto the local SSH client, and ultimately the local application.
Does SSH intercept the connections to the SOCK4 proxy?
No, the SSH Client is the SOCKS proxy.
I mean, it cannot be a "normal" SOCK4 proxy, because then it would directly proxy the connections to the remote hosts.
I suppose it's not really - the SSH Client and Server act together to achieve the function of a "normal" SOCKS proxy. The high-level result is that the proxy listens on one host, but forwards data from another host, with a magical link in between.
Furthermore, how does SSH handle responses from the remote hosts, i.e., how does it transfer them back over the SSH tunnel to the recipients on the local host?
TCP is a connection-oriented method of communication. That is to say that once a connection is established, data can flow in both directions, and is reliably identified as "related to that connection". With this information it is trivial to associate the data with arbitrary rules such as "forward to the SSH server, who will forward to 66.102.7.99".

Forward server HTTP traffic to handle in another device via SSH Tunnel

I'm developing some webhook required direct access public domain to internal machine, thinking use SSH tunnel to forward data, or got alternative solution?
Hosting server & development machine are in same network
192.168.1.2/24 (Hosting server)
2nd machine is virtual mapping using forticlient firewall without static or dynamic IP in visible in hosting server, so is 1 way initial communication right now.
In this case possible to setup SSH tunnel forward all traffic from 192.168.1.2:80 to handle in development machine port 8080?
How to ssh syntax look like?
Thanks.
This could be done by setting up an SSH tunnel to the remote machine:
ssh -L localhost:80:localhost:8080 development-system
Every request to port 80 on the hosting-server is now forwarded to port 8080 on the development-system.
Please note, that the port 80 on the hosting-server could only be used, when you start the SSH command as root. Also note that the port 80 is only accessible from the hosting-server. To access the port 80 on the hosting-server from everywhere use the following:
ssh -L 80:localhost:8080 development-system
Be sure that you want that.
A good introduction to the topic could be found at
https://www.ssh.com/ssh/tunneling/example
https://unix.stackexchange.com/questions/115897/whats-ssh-port-forwarding-and-whats-the-difference-between-ssh-local-and-remot

WCF, WAS, IIS and ports

Hi,
I have worked with WCF for a while now but there is somthing Im not clear on.
When hosting a WCF service in IIS the standard protocol will be http and the default port is 80. Its possible to change this portnr if needed.
Then its also possible to host a WCF service in IIS using the TCP protocol(WAS). The WCF service will however still publish its mex on port 80 on http prootocol but how do I see the port nr for the WCF TCP communication?
I Supose that I will have to open first the port nr for the mex(usually port 80) and then also the WAS(WCF TCP in IIS) port?
BestRegards
You can see which port TCP will use by going into the website configuration in IIS and looking at the site bindings, then looking for (or adding, if necessary) the net.tcp binding. Here is the documentation on how to configure bindings.
If I remember correctly, the default port is 808.

Is it possible to have a WCF/WAS service using net.tcp port 80 and IIS on the same port?

Does the TCPPortSharing service permit me to have a WAS activated TCP-Based service on the same port as IIS's port 80?
The picture below shows net.tcp at port 808. Can I change this to port 80? If the answer is "no" then am I misunderstanding the benefit of the tcpportsharing service?
The default port for net.tcp scheme that is published is 808. Similar to SSL 443.
This means that you don't need to specify 808 when sending a request to a net.tcp endpoint from WCF and give this information to all your clients. You can host multiple services listening on the default port using Windows activation service.
IIS will use port 80 by default but there is nothing stopping you from making net.tcp on 80 but you cannot share the port on different scheme.