Hoi
Ik had de indruk dat bij sip.encryptedsip.com ingaand ook encrypted is.
Blijkbaar heb ik dat verkeerd begrepen.
Vr.Gr,
Rob
sip.encryptedsip.com is in beide richtingen gecrypt. Gesprekken voor jou worden encrypted bij je afgeleverd, uitgaande gesprekken zal je moeten crypten.
Als ik je vraag goed begrijp is dat toch ook wat je wil?
Hoi
Binnenkomend gecrypt heeft hier nooit gewerkt, Met voor een config dan ook.
Vr.Gr,
Rob
Heb je dat ook al met je pjsip configuratie getest? Dat werkte bij mij direct. met als enige punt dat ik het wildcard certificaat moest accepteren (wat tegen de RFC’s in gaat).
Hoi
pjsip draait al een tijdje.
Maar zonder ‘media_encryption_optimistic=yes’ werkt encryptie dus niet. Blijkbaar heeft de andere kant niet door dat ie ook gecrypt moet versturen.
Bij VoIPGRID kan je dat dit instellen. Blijkbaar is het jou gelukt om eea ook zonder te laten werken. Een undocumented feature wellicht.
Vr.Gr,
Rob
Voor zover ik weet heb ik gewoon de documentatie gevolgd, dit is mijn pjsip config:
Transport inclusief NAT:
[transport-tls-nat]
type=transport
protocol=tls
method=tlsv1_3
ca_list_path=/etc/ssl/certs
allow_wildcard_certs=yes
bind=<locale IP van de server>
local_net=<mijn rfc1918 subnet>
external_media_address=<mijn publieke ip>
external_signaling_address=<mijn publieke ip>Registratie:
[freedom]
type=registration
transport=transport-tls-nat
outbound_auth=freedom
server_uri=sip:<klantnummer>@sip.encryptedsip.com
client_uri=sip:<klantnummer>@sip.encryptedsip.com
;contact_user=<klantnummer>
max_retries=20000 ; There is no "unlimited" option, with retry_interval=60
retry_interval=60 ; this is almost two weeks of retries, should be enough
forbidden_retry_interval=600
expiration=3600
line=yes
endpoint=freedom
auth_rejection_permanent=false
support_outbound=yesAuthenticatie:
[freedom]
type=auth
username=<klantnummer>
password=<password>Endpoint:
[freedom]
type=endpoint
disallow=all
allow=alaw
aors=freedom
context=from-freedom
media_encryption=sdes
acl=freedom
rewrite_contact=true
direct_media=false
transport=transport-tls-nat
from_user=<klantnummer>
from_domain=sip.encryptedsip.com
outbound_auth=freedomIdentify:
[freedom]
type=identify
match=195.35.114.0/23,185.103.76.0/22
endpoint=freedomAOR:
[freedom]
type=aor
contact=sip:<telefonnummer>@sip.encryptedsip.comDe acl waar in het endpoint naar verwezen wordt staat in acl.conf:
[freedom]
deny=0.0.0.0/0.0.0.0
permit=195.35.114.0/255.255.254.0
permit=185.103.76.0/255.255.252.0Hoi
Mijn huidige Asterisk is oud en heeft geen ‘support_outbound’. Dus
‘support_outbound=yes’ heb ik niet geprobeerd.
Eea doet de server nogal wat bijhouden van de client. En mogelijk dat dit het gedrag beïnvloed. Iets anders kan ik me niet bedenken.
Vr.Gr,
Rob
Die support_outbound is vooral handig icm. NAT, het zorgt ervoor dat alle connecties geïnitieerd worden vanuit asterisk waardoor je geen gedoe hebt met port forwards enzo. Als je die forwards wel hebt staan (en dat vermoed ik wel, het werkt immers wel) zou het geen verschil moeten maken, het doet in ieder geval niets met het wel/niet crypten van een gesprek.
Belangrijk voor de crypto op de gesprekken zijn de verwijzingen naar sip.encryptedsip.com (ipv. de standaard freedom.nl adressen) en media_encryption=sdes.
Hoi
Mijn server is tevens gateway en router;
Het enige dat hier via NAT loopt is usenet. Asterisk praat dus direct met de buitenwereld.
Een gesprek van buiten naar binnen kan natuurlijk alleen maar vanaf buiten geïnitieerd worden.
Als ik de RFC even vluchtig doorblader gaat het inderdaad over NAT. Zorgen dat de server de client kan bereiken. Zo is er continue verkeer om NAT wakker te houden. De server houd nogal wat bij hiervoor. Oa een UUID;
https://www.rfc-editor.org/rfc/rfc5626
Ik denk dat dit het gedrag (onbedoeld) beïnvloed. Wellicht een bug gebuikt als feature.
Als dit inderdaad zo is zou het zonder ‘support_outbound=yes’ dus niet moeten werken.
Als ik een verse Asterisk heb zal ik er nog eens naar kijken. En als het inderdaad uitmaakt dan ook een eens via IPv6 proberen. TLS werkt sowieso via IPv6.
Vr.Gr,
Rob