The problem is that I know next to nothing about SIP, or FreeSWITCH, yet have been tasked with figuring this out.
The setup:
The FreeSWITCH client sends a subscribe to a remote server to receive presence updates. The client is behind a fairly restrictive firewall and NAT.
The server replies with the normal unauthorized, and Sofia replies, and we receive the SIP/2.0 200 OK message, its VIA header contains an rport for a port number we don't have open or forwarding to our FreeSWITCH installation.
We never receive the notify that ought to follow the 200 OK.
Subsequent subscribes returns different rport designations.
Is there a way to configure FreeSWITCH/Sofia to always use a specific port for the rport parameter?
Edit: We never managed to solve it, but the remote service did solve it by adding the correct routes to their firewall.
Is the far end server setup to allow NOTIFY to be sent to your client?
If you receive the 200 OK response to the initial SUBSCRIBE then that sets up the SIP dialog I believe (the dialog is a end-point to end-point association).
BTW you set up FS to be the presence watcher client? Thats cool since I tried doing that but the documentation gave me a headache and moved on to other things.
Since you sent the initial subscribe NAT shouldn't be a problem right? since rport should have the port to use. I would always use port 5060, have your FW people let udp port 5060 port in and out freely, use Fail2ban to filter your traffic.
But have no idea how FS works, and NAT firewalls are the greatest evil :-). Sorry and best of luck.
Related
I installed Wireshark on macOS High Sierra and captured some network trafic while making HTTP calls to a local server using CURL.
The traffic captured in wireshark only showed TCP packets. When looking at the data whitin the TCP packets I could see the HTTP packets, but these were not recognized by Wireshark as the packet protocol.
Any way to make it properly parse the HTTP packets?
Here's an example capture:
One guess I had was that Wireshark only recognises a packet as HTTP if it's on port 80. If this is so, is there any way to change this setting?
P.S. No HTTPS involved here, just plane old HTTP from a client to a REST API.
Ok, figured out the issue.
My server was exposed on port 5000 (which is the default Flask port).
Turns out that port 5000 is conventionally used for IPA packets, which is a GSM over IP protocol. Wireshark aparently used the port number to determine the type of packet, and so it misclasified it as an IPA packet.
Once I moved my server to another port (e.g. 5001) - the problem was gone.
P.S. See https://osqa-ask.wireshark.org/questions/9240/data-which-has-been-sent-over-tcpip-has-been-recognized-by-wireshark-as-ipa-protocol for more details.
To supplement #MartanRubin's answer, it's also possible to indicate to WireShark that port 5000 is not GSM over IP. In Edit → Preferences → Protocols → GSM over IP remove port 5000 from the "TCP port(s)" field:
To persist the preference you also need to add 5000 to HTTP protocol "TCP port(s)" field. Then they survive restart (tested in a custom profile). Note however, that when you open GSM over IP protocol's preferences, 5000 is still there, but doesn't have effect. But when I save it (click OK button), my /home/user/.config/wireshark/profiles/CustomProfile/decode_as_entries gets messed up again, and I need to repeat the process on both protocol's "TCP port(s)" field. A counter-intuitive UI, I would say.
In MDN's proxy example, I have seen that they use 127.0.0.1:65535 as an invalid url
(link to the source):
const allow = "DIRECT";
const deny = "PROXY 127.0.0.1:65535";
...
function FindProxyForURL(url, host) {
if (blockedHosts.indexOf(host) != -1) {
browser.runtime.sendMessage(`Proxy-blocker: blocked ${url}`);
return deny;
}
return allow;
}
Is there anything special about port 65535? Is it safe to assume that no process will ever listen to that port?
In the documentation of Proxy Auto-Configuration (PAC) files, I did not see a straightforward way to block requests otherwise. For instance, there is DIRECT, PROXY, SOCKS but no REJECT or DENY. I assume that PROXY 127.0.0.1:65535 is the official way to deny requests.
Is it safe to assume that sending requests to 127.0.0.1:65535 will reject them?
Is it safe to assume that sending requests to 127.0.0.1:65535 will reject them?
No, it's not safe.
It's just the very last port on the local machine. I'm perfectly able to open it without any special privileges and send data to it.
They are simply using it as a valid address but a port that's unlikely to be used. Not the best solution, but probably good enough for example code.
There's no special stipulation and 65535 a valid port for a proxy. If you just happen to run a valid proxy there the example will fail to block.
Normally "9" is used as the default port for "discard service". 65535 is nothing special but the biggest possible port number. I assume they use it because they believe no one will listen to the port.
However, this approach is not safe because 1) anyone can write a server socket listening to port 65535; and 2) the port number might be randomly allocated to a client as ephemeral port.
In addition to the other answers, the Discard Protocol (port 9) is the closest equivalent to /dev/null. To quote from the Wikipedia article:
The Discard Protocol is the TCP/UDP equivalent of the Unix filesystem node /dev/null. Such a service is guaranteed to receive what is sent to it and can be used for debugging TCP and/or UDP code requiring a guaranteed reception of payload sent.
On various routers, this TCP or UDP port 9 for the Discard Protocol (or port 7 for the Echo Protocol relaying ICMP datagrams) is also used by default as a proxy to relay Wake-on-LAN (WOL) magic packets from the Internet to hosts on the local network in order to wake up them remotely (these hosts must also have their network adapter configured to accept WOL datagrams and the router must have this proxy setting enabled, and possibly also a configuration of forwarding rules in its embedded firewall to open these ports on the Internet side).
Also blocking requests via the proxy API is not the typical usage. Instead the webRequest API is better suited for blocking requests. There are discussions to change the example.
I assume that explains why there is no explicit support for denying requests in the PAC de facto standard, and why the workarounds of redirecting traffic to unused ports or domains are used.
I'm using Twilio to send and respond to messages. It was working normally, but since we moved to bay area the responding function doesn't work now.
So what happens is when the user send message to us(the IP address of our own computers) from their phones, our server can't receive anything. When we check our Twilio account, we know that the msg was indeed sent to the Twilio server. So we think it's the problem of linking between Twilio server and our IP address. We are suspecting that the IP address is virtual IP address here, which makes Twilio server can't find us. Is our suspection correct? if yes, what should we do? If not, what would be the possible problems?
Apologize for having a description not very clear, but it's pretty much everything of the problem. Please tell me if you need any additional information.
You probably need to use a dynamic dns service. Then you need to find what port Twilio sends the SMSs to the client(your computer), and make sure your firewall is forwarding that port to your computer. Odds are this is a firewall issue, especially since you say everything worked before you moved. Has there been a change in your network setup? You need to be aware of both hardware and software firewalls in your setup.
How is the firewall configured on your router? You need to forward requests to your router to your local IP address. Example: My local ip is 192.168.1.5 my external ip is 245.932.4.3 (This is the value you get from myipaddress.com) Thus you need to set your router (which has ip 245.932.4.3) to forward requests on port x (where x= the twilio outgoing port) to 192.168.1.5
Most proxy servers perform the job of forwarding data to an appropriate "real" server. However, I am in the process of designing a distributed system in which when the "proxy" receives a TCP/IP socket connection, the remote system actually connects with a real server which the proxy nominates. All subsequent data flows from remote to the real server.
So is it possible to "forward" the socket connection request so that the remote system connects with the real server?
(I am assuming for the moment that nothing further can be done with the remote system. Ie the proxy can't respond to the connection by sending the IP address of the actual server and the remote connections with that. )
This will be under vanilla Windows (not Server), so can't use cunning stuff like TCPCP.
I assume your "remote system" is the one that initiates connection attempts, i.e. client of the proxy.
If I get this right: when the "remote system" wants to connect somewhere, you want the "proxy server" to decide where the connection will really go ("real server"). When the decision is made, you don't want to involve the proxy server any further - the data of the connection should not pass the proxy, but go directly between the "remote system" and the "real server".
Problem is, if you want the connection to be truly direct, the "remote system" must know the IP address of of the "real server", and vice versa.
(I am assuming for the moment that nothing further can be done with
the remote system. Ie the proxy can't respond to the connection by
sending the IP address of the actual server and the remote connections
with that. )
Like I said, not possible. Why is it a problem to have the "proxy" send back the actual IP address?
Is it security - you want to make sure the connection really goes where the proxy wanted? If that's the case, you don't have an option - you have to compromise. Either the proxy forwards all the data, and it knows where the data is going, or let the client connect itself, but you don't have control where it connects.
Most networking problems can be solved as long as you have complete control over the entire network. Here, for instance, you could involve routers on the path between the "remote system" and the "real client", to make sure the connection is direct and that it goes where the proxy wanted. But this is complex, and probably not an option in practice (since you may not have control over those routers).
A compromise may be to have several "relay servers" distributed around the network that will forward the connections instead of having the actual proxy server forward them. When a proxy makes a decision, it finds the best (closest) relay server, tells it about the connection, then orders the client to connect to the relay server, which makes sure the connection goes where the proxy intended it to go.
There might be a way of doing this but you need to use a Windows driver to achieve it. I've not tried this when the connection comes from an IP other than localhost, but it might work.
Take a look at NetFilter SDK. There's a trial version which is fully functional up to 100000 TCP and UDP connections. The other possibility is to write a Windows driver yourself, but this is non-trivial.
http://www.netfiltersdk.com
Basically it works as follows:
1) You create a class which inherits from NF_EventHandler. In there you can provide your own implementation of methods like tcpConnectRequest to allow you to redirect TCP connections somewhere else.
2) You initialize the library with a call to nf_init. This provides the link between the driver and your proxy, as you provide an instance of your NF_EventHandler implementation to it.
There are also some example programs for you to see the redirection happening. For example, to redirect a connection on port 80 from process id 214 to 127.0.0.0:8081, you can run:
TcpRedirector.exe -p 80 -pid 214 -r 127.0.0.1:8081
For your proxy, this would be used as follows:
1) Connect from your client application to the proxy.
2) The connection request is intercepted by NetFilterSDK (tcpConnectRequest) and the connection endpoint is modified to connect to the server the proxy chooses. This is the crucial bit because your connection is coming from outside and this is the part that may not work.
Sounds like routing problem, one layer lower than TCP/IP;
You're actually looking for ARP like proxy:
I'd say you need to manage ARP packets, chekcing the ARP requests:
CLIENT -> WHOIS PROXY.MAC
PROXY -> PROXY.IP is SERVER.IP
Then normal socket connection via TCP/IP from client to server.
I'm trying to see the results of an incoming ping on a target windows machine. This is needed to verify that the ping, which is running in a background thread, is being sent from the originator.
I have tried netstat to no avail. Are there any other approaches I could try?
Thanks.
Ping is an ICMP packet and doesn't create a TCP connection (hence you won't see it in netstat). On Linux, I'd add a rule to the firewall.
The most simple solution for your case might be to open a connection and close it. That will add it to the output of netstat with WAIT_CLOSE.
As Aaron Digulla already noted, ping is ICMP. This also means the originator even less trustable then with TCP; there's no SYN/ACK handshake. You just get an IP packet on your host, and you have to trust the header fields. Anyone can spoof those header fields, with almost no restrictions (It might be a bit challenging to get an IP claiming to come from 127.0.0.1 past a router)
Therefore, ICMP is not suitabel for verification tasks. You need a challenge/response protocol. TCP works reasoanbly well as long as you can trust the network but not necessarily all hosts on it (a reasonable assumption for the Internet. Not strong enough for financial transactions, which is why they use SSL)