[sr-dev] [kamailio/kamailio] Problem with IPv6, TLS and advertise param (#1581)
Joel Serrano
notifications at github.com
Wed Jul 4 01:51:24 CEST 2018
### Description
We want to be able to handle reINVITEs over TLS so calls can reconnect when they switch networks (for example from wifi to mobile data).
We have the following config in kamailio.cfg:
```
listen=tls:1.1.1.1:443 advertise sbc01.domain.com:443
listen=tls:[AAAA:BBBB:CCCC:DDDD:EEEE:FFFF:GGGG:HHHH]:443 advertise sbc01.domain.com:443
listen=udp:1.1.1.1:5060
```
In order to not break TLS validation (certs) we set the advertise to the FQDN so all headers are set with the FQDN and not the IP address, also notice no `[]` in the FQDN part of advertise IPv6 line. We do this, because we found that without the advertise, all headers have the IP address, which is also OK, but if the TCP connection breaks and the client reconnects, it will send the connection to the top request-route header, if it's an IP, the TLS validation will beak because the cn= doesn't match, having the FQDN there, the cn= will match and the request will continue.
Example scenario:
* IPv4 call:
Our public domain is `sip.domain.com` that has SRV records pointing to `sbc01.domain.com` and `sbc02.domain.com`. For this example let's stick to `sbc01.domain.com`.
Kamailio: 1.1.1.1 / sbc01.domain.com
Media server: 2.2.2.2
Client <---TLS 443---> Kamailio <---UDP 5060---> Media server
Example call:
Let's focus on the INVITE that Kamailio sends to the media server (the *blue* INVITE in the screenshot)
The headers look like this:
```
INVITE sip:test at 2.2.2.2:5060 SIP/2.0
Record-Route: <sip:1.1.1.1;r2=on;lr=on;ftag=eTdR161Ub;did=916.2391;nat=yes>
Record-Route: <sip:sbc01.domain.com:443;transport=tls;r2=on;lr=on;ftag=eTdR161Ub;did=916.2391;nat=yes>
...
```
Which is correct, if the client has to send a reINVITE, it will do a DNS request to sbc01.domain.com and depending if it has AAAA and A records, and what the client's current transport is (ipv6/ipv4) it will select and use what it needs.
..Now let's say the same scenario, but origin transport is IPv6 this time..
* IPv6 call:
Same scenario as above, same invite, this time the headers look like this:
```
INVITE sip:test at 2.2.2.2:5060 SIP/2.0
Record-Route: <sip:1.1.1.1;r2=on;lr=on;ftag=iMwhZbnTA;did=fda.2803>
Record-Route: <sip:[sbc01.domain.com]:443;transport=tls;r2=on;lr=on;ftag=iMwhZbnTA;did=fda.2803>
```
(notice the FQDN surrounded by `[]`)
#### Reproduction
Add the `advertise` option on a `listen=` param with transport tls and using an IPv6.
Observe the format of the headers the `record_route()` function adds to the request.
### Possible Solutions
When setting a FQDN instead of an IP address (v4/v6) in the `advertise` option; never enclose it with `[]` ? It's a suggestion, maybe what I'm saying is completely nuts.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
# kamailio -v
version: kamailio 5.1.4 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 6.3.0
```
* **Operating System**:
```
OS: Debian stretch 9.4
Kernel: Linux kamailio 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1581
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20180703/1877e9ed/attachment.html>
More information about the sr-dev
mailing list