Just noticed that on Chrome only, RTCIceCandidate no longer returns an IP, but rather an obfuscated address.
RTCIceCandidate
address: "a5b3ef18-2e66-4e24-91d2-893b93bbc1c1.local"
candidate: "candidate:169888242 1 udp 2113937151 a5b3ef18-2e66-4e24-91d2-893b93bbc1c1.local 47871 typ host generation 0 ufrag 7dHv network-cost 999"
component: "rtp"
foundation: "169888242"
port: 47871
priority: 2113937151
protocol: "udp"
relatedAddress: null
relatedPort: null
sdpMLineIndex: 0
sdpMid: "0"
tcpType: ""
type: "host"
usernameFragment: "7dHv"
Notice the first property of RTCIceCanadate is "address", and "ip" is no longer part of this object.
The following code determines the local IP address of a browser. Still works on MOZ.
function discover()
{
try{
//Get Local IP
window.RTCPeerConnection = window.RTCPeerConnection || window.mozRTCPeerConnection || window.webkitRTCPeerConnection; //compatibility for firefox and chrome
if (pc)
pc.close();
pc = new RTCPeerConnection({iceServers:[]});
pc.onicecandidate = onIceCandidate;
pc.createDataChannel("");
pc.createOffer(pc.setLocalDescription.bind(pc), noop);
} catch (e)
{ console.log(e.message);}
}
function noop()
{
}
function onIceCandidate(ice)
{
console.log(ice.candidate);
if(!ice || !ice.candidate || !ice.candidate.candidate) return;
var my_ip = /([0-9]{1,3}(\.[0-9]{1,3}){3}|[a-f0-9]{1,4}(:[a-f0-9]{1,4}){7})/.exec(ice.candidate.candidate)[1];
this.onicecandidate = noop;
ip = my_ip.split(".")[0]+'.'+my_ip.split(".")[1]+'.'+my_ip.split(".")[2];
}
Is WebRTC officially now a fractured standard? MOZ still lists "ip" as a member of RTCIceCandidate, with no mention of the "address" member that Chrome returns.
Is there a way to de-obfusucate the mDNS address back to an ip address without forcing users to mess around with browser settings they don't understand?
Chrome is not broken, the WebRTC standard is evolving to prevent sites from collecting local addresses by diverting the WebRTC API. If you used this hack to obtain local addresses, you might need to find another approach.
Here are the corresponding issues for Chromium and Firefox, and the current IETF draft for WebRTC mDNS candidates.
The ip field got renamed to address in the W3C webrtc specification at some point since these days the field can contain either an IP address or a mdns hostname.
What you are seeing is part of the rollout of the WebRTC host candidate obfuscation which is described ħere which is happening in Chrome 75. You can not decode this mdns hostname in the browser.
If you have a legitimate use-case you might want to ask for it to be considered in that mailing list thread.
You can disable this feature in Chrome
goto chrome:://flags
and disable "Anonymize local IPs exposed by WebRTC"
I noticed that this was happening, only returning an mDNS address (for more information about the obfuscation, read this great article completely explaining what happened).
However, I did find a new repository that seems to "fix" this (working, but not exposing the private ip, only the public). It can be found here, and the example can be found here.
Related
I need to extract the user IP address (v4).
I have the following code to do so:
HttpContext.Connection.RemoteIpAddress.MapToIPv4().ToString();
The problem is that in this case I am getting cloud flare ip address.
How can I get the forwarded v4 IP address?
Thanks
Cloudflare passes all HTTP request headers to your origin web server and adds additional headers.
The header:
CF-Connecting-IP
provides the client IP address connecting to Cloudflare to the origin
web server.
You can also use the header:
X-Forwarded-For
which maintains proxy server and original visitor IP addresses.
For more information about the CloudFlare headers you can refer to the documentation
Actually, you can created a method that tries to check all these headers and return the client IP address value.
private string getRemoteIpAddress(HttpContext accessor) {
// try reading the CloudFlare client IP address header
if (!string.IsNullOrEmpty(accessor.Request.Headers["CF-CONNECTING-IP"]))
return accessor.Request.Headers["CF-CONNECTING-IP"];
// try reading the proxy server and original visitor IP addresses header
var ipAddress = accessor.GetServerVariable("HTTP_X_FORWARDED_FOR");
if (!string.IsNullOrEmpty(ipAddress)) {
var addresses = ipAddress.Split(',');
if (addresses.Length != 0) return addresses.Last();
}
// try reading the remote IpAddress without a proxy
return accessor.Connection.RemoteIpAddress.ToString();
}
I am trying to create a SAP RFC connection to a new system.
AFAIK the firewall (in this case to port 3321) is open.
I get this message at the client:
RFC_COMMUNICATION_FAILURE (rc=1): key=RFC_COMMUNICATION_FAILURE, message=
LOCATION SAP-Gateway on host ax-swb-q06.prod.lokal / sapgw21
ERROR timeout during allocate
TIME Thu Jul 26 16:45:48 2018
RELEASE 753
COMPONENT SAP-Gateway
VERSION 2
RC 242
MODULE /bas/753_REL/src/krn/si/gw/gwr3cpic.c
LINE 2210
DETAIL no connect of TP sapdp21 from host 10.190.10.32 after 20 sec
COUNTER 3
[MSG: class=, type=, number=, v1-4:=;;;]
And this message on the SAP server
Any clue what needs to be done, to get RFC working?
With this little info no one can know what the issue is here.
But it is something related to your network and SAP system configuration.
I guess your firewall does some network address translation (NAT) and the new IP behind the firewall does not match anymore with the known one. SAP is doing some own IP / host name security checks.
If not already done, check with opening the ports 3221, 3321 and 4821 in the firewall. Also check the SAP gateway configuration which IP addresses and host names are configured to be valid ones for it (look at what is traced in the beginning of the gateway trace file dev_rd at ABAP side).
Also consider if maybe the usage of a SAProuter would be the better option for your needs.
it works in my case if ashost is the host name, and not an IP address!
Do not ask me why, but this fails:
Connection(user='x', passwd='...', ashost='10.190.10.32', sysnr='21', client='494')
But this works:
Connection(user='x', passwd='...', ashost='ax-swb-q06.prod.lokal', sysnr='21', client='494')
This is strange, since DNS resolution happens before TCP communication.
It seems that the ashost value gets used inside the connection. Strange. For most normal protocols (http, ftp, pop3, ...) this does not matter. Or you get at least a better error message.
I am using Perfect Framework for my server side application running on an AWS EC2 instance. I am using the following code to get client IP address.
open static func someapi(request: HTTPRequest, _ response: HTTPResponse) {
var clientIP = request.remoteAddress.host }
This was working fine until I installed ssl certificate on my EC2 instance and start redirecting incoming traffic to port 443.
Now this code gives me the ip of my server, i think due to the redirect, Perfect somehow think request comes from itself.
Is there any other method to get client IP address? Or do i have to try something else?
Thanks!
For anyone struggling for the same problem, original client ip can be found in one of the header fields called "xForwardedFor" if there is a redirect, like the following:
var clientIP = request.remoteAddress.host
let forwardInfoResut = request.headers.filter { (item) -> Bool in
item.0 == HTTPRequestHeader.Name.xForwardedFor
}
if let forwardInfo = forwardInfoResut.first {
clientIP = forwardInfo.1
}
Hope this helps somebody, cheers!
Perhaps you should ask the people you are paying for support and whom manage the infrastructure how it works before asking us?
The convention, where an http connection is terminated elsewhere than the server is to inject an x-forwarded-for header. If there is already such a header, the intermediate server injects the client IP address at the front of the list.
I have a Windows setup with multiple IP's, and wishes my Rebol script (on Rebol/Core 2.78) to make individual bind and listen to the same port number on each of those IP's.
Until very recently I thought the syntax to do this was:
Port1Test: open/lines tcp://:80 browse http://10.100.44.6?
Port2Test: open/lines tcp://:80 browse http://10.100.44.7?
But it turns out the Port2Test line fails, as the browse http://10.100.44.6? part is totally ignored (and now searching, I can't even locate where I got that syntax in the first place).
Reading up on the documentation all I can find on how to specify a listening port is like this:
Port1Test: open/lines tcp://:80
Probing the Port1Test port reveals most settings set to none, and a few set as follows:
scheme: 'tcp
host: none
port-id: 80
local-ip: 0.0.0.0
local-port: 80
So I attempted to modify those values like this:
Port1Test: open/lines tcp://:80 ; Create port, as before. Then modify below
Port1Test/host: 10.100.44.6 ; Might this be the binding interface?
Port1Test/port-id: 1 ; I guess this is just an id?
Port1Test/local-ip: 10.100.44.6 ; This ought to be the binding interface.
Port2Test: open/lines tcp://:80 ; Create port, as before. Then modify below
Port2Test/host: 10.100.44.7 ; Might this be the binding interface?
Port2Test/port-id: 2 ; I guess this is just an id?
Port2Test/local-ip: 10.100.44.7 ; This ought to be the binding interface.
Unfortunately all variations of the above modifications, including swapping the IP values for Port1Test and Port2Test, fails when creating Port2Test. :-(
I'm sure there's something I'm overlooking, but I can't find any hints anywhere about how to initialize a port while binding it to a specific interface.
Any hints highly appreciated!
Edit:
The way Rebol bind to interfaces is now pretty evident to me - but how to modify it it still a mystery.
Let’s say I have two IP’s (== interfaces) associated to one networking card: 10.100.1.1 and 10.100.1.2.
On 10.100.1.1:80 I setup a Tomcat application that I know can bind to that specific interface.
Then I start a REBOL application, that also claim port 80.
They will both run happily, and each be accessible on only one IP, as if the Rebol application had bound to 10.100.1.2.
Then I shut down the Tomcat application, and attempt to start it. This turns out not to be possible, as the interface is in use.
And if I access both of the IP’s, it turns out the Rebol application is accessible on both IP’s.
It’s not an active mechanism in Rebol that at work here, but because Rebol claims the 0.0.0.0 interfaces (In the context of servers, 0.0.0.0 means "all IPv4 addresses on the local machine"), which is translated to any currently available interface, and a deferred claim to interfaces as they become available.
It would be really nice to find out how to change Rebols default interface of 0.0.0.0 to something else at create time of the port!
Rebol2 listen ports bind by default to all available IPv4 interfaces (0.0.0.0), and to the extent of my knowledge, unfortunately, there is no way to change that.
FYI, Rebol2 exposes existing IPv4 interfaces using the interfaces port mode:
>> p: open tcp://:8000
>> probe get-modes p 'interfaces
[make object! [
name: "if19"
addr: 10.27.10.110
netmask: 255.255.255.252
broadcast: 10.27.10.111
dest-addr: none
flags: [broadcast multicast]
] make object! [
name: "lo0"
addr: 127.0.0.1
netmask: 255.0.0.0
broadcast: none
dest-addr: none
flags: [multicast loopback]
] make object! [
name: "if16"
addr: 192.168.1.4
netmask: 255.255.255.0
broadcast: 192.168.1.255
dest-addr: none
flags: [broadcast multicast]
]]
Alas, this is read-only...(the documentation says not settable).
You can find a list of all port modes here, in case it is of any help to you.
We use an embedded ActiveMQ broker and create it like this(a bit simplified) :
BrokerService brokerService = new BrokerService();
brokerService.addConnector("tcp://1.2.3.4:61610");
brokerService.start();
The problem we have is that the broker is listening to the hostname instead of the IP-address and this does not work in our case. How can I force the brokerService to listen on the IP address instead of the hostname.
Here is what the log says when starting the broker:
2015-01-20 15:16:03,414 qtp833534789-27 INFO BrokerService - Apache ActiveMQ 5.10.0 (b1653842572, ID:ABC123-59162-1421763362756-0:1) is starting
2015-01-20 15:16:04,948 qtp833534789-27 INFO TransportServerThreadSupport - Listening for connections at: tcp://myhostname.mydomain.local:61610
2015-01-20 15:16:04,948 qtp833534789-27 INFO TransportConnector - Connector tcp://myhostname.mydomain.local:61610 started
A TCP listener can never listen to a DNS name. It's always bound to one or many interface(s)/IP address(es).
In this case, ActiveMQ helps you out by reverse resolving the DNS name from the IP because it's easier to understand what's going on in the logs when you read a logical DNS name rather than some number.
ActiveMQ has some code like this
protected String resolveHostName(ServerSocket socket, InetAddress bindAddress) throws UnknownHostException {
String result = null;
if (socket.isBound()) {
if (socket.getInetAddress().isAnyLocalAddress()) {
// make it more human readable and useful, an alternative to 0.0.0.0
result = InetAddressUtil.getLocalHostName();
} else {
result = socket.getInetAddress().getCanonicalHostName();
}
} else {
result = bindAddress.getCanonicalHostName();
}
return result;
}
To replace the IP with a DNS once the socket is indeed bound. I guess you have not even tried using the IP address, since it should work.
Try this:
brokerService.addConnector("tcp://0.0.0.0:61610");