Register request doesn't send auth headers

[TurabG]

I have a fresh installation here. Using external profile. I couldn't manage to register the gateway until the provider had something changed on their side. The gateway registered for 10 minutes, got deregistered and now it can't register again.

My sngrep shows that first register invite returns 401 from the provider, with a WWW-Authenticate header. It is expected that the second request must send auth header so that second response from the provider should be 200. When I had it registered for only once for about 10 minutes, I can see this auth header in my second request. But now, it keeps sending completely the same request over and over again, without an auth header, resulting 401 response.

I talked to provider again and asked them to check their logs and they said exactly what I was expecting that my requests lacked auth header.

Why doesn't it send the auth header? Register is set to true in gateway settings.

 

[Adrian Fretwell]

Possibly a NAT problem, make sure your switch is actually seeing the message from your provider with the WWW-Authenticate header, otherwise it can do exactly as you describe.

 

[TurabG]

I don't think it's a NAT problem because I have 5060 port forwarded to this local machine and sngrep catches the SIP traffic coming in from the provider. Does NAT tamper with the content, like stripping out a header?

Nevertheless, provider already sends a WWW-Authenticate header, I can see it in sngrep watch. The problem is that the local machine doesn't respond with one. I mean the problem is not with the inbound traffic but rather with outbound. The Fusion box does not respond the provider with an auth header.

 

[Adrian Fretwell]

OK, I'm mindful of the fact that you say this has been working. Not sure how you have configured your box, but normally you would talk to you provider via port 5080 using the external SIP profile. Do you have your provider IP in the ACL?

NAT, or more specifically NAT helpers (ALGs) do tamper with content, but I have never know it to remove a header. The most common problem with NAT helpers is changing the IP addresses (or anything that looks like an IP address) in Contect headers, and SDP bodies.

 

[TurabG]

This is a fresh installation but I changed the port from 5080 to 5060 in external profile. There are no ALGs enabled in our router concerning SIP or similar protocols and there is already another machine (3CX) working on the same router. (No they don't overlap because it uses a different port.)

Even if I had a NAT issue, why wouldn't I see the auth header going out from the Fusion instance? I mean I am watching the SIP traffic from the Fusion machine itself, before it gets to router, before any possible NAT issue to be considered. I can see the WWW-Authentication header reaching to my instance. So the inbound traffic (from the provider to the instance) is perfect, there are no NAT issues. After that, my instance, the local machine itself, is not sending an auth header back. It just keeps sending the copy of the first register request.

This can't be an issue with the network or NAT in anyway. Nothing outside can interfere with what the instance is producing as a packet to be broadcasted. NAT problem and alike can arise only when after it broadcasted, not before.

 

[Adrian Fretwell]

I changed the port from 5080 to 5060 in external profile

So what port is you internal profile running on?

 

[TurabG]

That question made me understand how internal and external profiles worked. I thought those profiles are only a preconfigured set of variables to use with different gateways of your choice. I know understand that internal profile is meant for the clients connecting to this instance and external is meant for the outer communication like for gateways.

Internal profile is using port 5060 and looks like my changing the external profile to 5060 broke things. I changed the port of internal profile to something else and now it works. Thank you.

 

[DigitalDaz]

I don't think it's a NAT problem because I have 5060 port forwarded to this local machine and sngrep catches the SIP traffic coming in from the provider. Does NAT tamper with the content, like stripping out a header?

Nevertheless, provider already sends a WWW-Authenticate header, I can see it in sngrep watch. The problem is that the local machine doesn't respond with one. I mean the problem is not with the inbound traffic but rather with outbound. The Fusion box does not respond the provider with an auth header.

Freeswitch should definitely send the auth header if challenged.

You can check Freeswitch itself is receiving the auth header by doing a:

sofia global siptrace on

in fs_cli

to turn it off again:

sofia global siptrace off

 

[Adrian Fretwell]

Freeswitch should definitely send the auth header if challenged.

I agree, but I seem to remember something about the internal profile not processing outbound register attempts and therefore does not respond to a WWW-Authenticate header. I could be wrong, maybe mis-remembering.

 

[TurabG]

Freeswitch should definitely send the auth header if challenged.

It definitely did not. By sngrep, I could see a legitimate WWW-Authenticate header coming in as a response from the provider and I could see that the outgoing subsequent requests did not include any authentication header.

I don't know how it is related but changing the internal profile's port to something else has fixed it. I had changed the external profile's port to 5060 because the provider doesn't accept other ports.* But somehow having both internal and external profiles use the same port, this thing happens and outgoing requests does not include auth header.

* It produces another question here. I am connecting to provider with 5060 port, independent from the port I want to receive the response to. So in theory, I can send requests to the provider on 5060 port and receive response on 5070 for example. But when I change the local port to 5070 in external profile and in the router; I receive no response. Although outgoing requests are sent to the port I wish to receive the response to, I can see only outgoing requests, but no response. Provider says they don't receive the requests at all which I can see by sngrep.

Aside from what provider said about not receiving my requests; can they have their outgoing port fixed to 5060 no matter what port the client sends in contact header? This is nonsensical but that's the only possibility I can think of. They just ignore the port in my contact header and try to contact me on port 5060, maybe?

Edit: To test my theory, I changed the external profile port to 5070 and in my router I forwarded external port 5060 to internal 5070 of FusionPBX. No, I still don't receive response neither in 5070 nor in 5060. I simply can not change the port in external profile other than 5060.

 

[TurabG]

Here is an interesting update:

I have been trying to change the port to something other than 5060, in external profile, but as I explained in my previous comment, I can make it work only on port 5060. There is no firewall or NAT issue in the router. Today I wasn't able to register with port 5060 either, with the same malfunction, that Freeswitch not sending an auth header in the second reg. request to the provider, resulting the provider constantly responding with HTTP 401.

I have now checked iptables entries and surprisingly saw my provider's IP in the block list! Under sip-auth-ip chain, it was blocked. Now comes up two questions;

1- How did it end up in iptables block list?
2- If it's blocked (as it was obviously in the ruleset) then how comes I am seeing traffic coming in from and going out to the provider? (With only the outgoing request lacking an auth header.)

I have deleted the corresponding rule and without changing any other setting, it registered right away, sending an auth header this time.

 

[Adrian Fretwell]

With both sngrep and tcpdump you will see packets that arrive on your network interface before they hit iptables.

 

[DigitalDaz]

With both sngrep and tcpdump you will see packets that arrive on your network interface before they hit iptables.

Hence why I said to use the siptrace in sofia.