Expressway Certificate Testing for MRA

[VCsupport17]

Hi,

We are currently testing certificates for Expressway Core and Edge.

To give you an overview on the current setup, the Expressway Edge is deployed single DMZ (single NIC) and its IP address is NATed to Public IP. The Expressway Core is communicating with Expressway Edge with its internal IP 10.100.100.1 and not the NAT IP. On Expressway Core traversal client zone configuration, the peer address configured is 10.100.100.1. 

We have configured two separate traversal zones - for MRA and B2B.

B2B traversal zone is active but MRA is inactive and TLS not established due to certificates issues. 

We generated CSR on both Expressways and let it signed by our internal CA for testing purposes only. But in actual production, we will pass the CSR of the Expressway Edge to Public CA for signing.

We already uploaded the signed certificates by our internal CA to both Expressways as well as the Root CA.

But checking the secure traversal test, we encountered this issue:

Does we need to enter the FQDN of the Expressway Edge and not its IP address when testing the secure traversal? Because when we try the FQDN (edge.external.com) it says unreachable. Or because there is no communication between Core and Edge on that FQDN? Do we need to allow Core to communicate with Expressway Edge FQDN?

We already created Expressway Edge FQDN on external DNS and can be resolve with its NAT IP (Public). SRV records were already created on external DNS as well.

Please advice. Thank you in advance.

[Adam Miles]

For a single NIC DMZ expressway you need to have your internal DNS pointing to the external IP address for Expressway Edge.  This means Expressway-C talks to E via the external IP - this will need NAT reflection to be set up on your external firewall to keep the traffic internal.  It's why I prefer dual NIC setup, so much simpler and also easier to diagnose so push for that if you can.

Check the basic config guide, appendix 4.

http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-8/Cisco-Expressway-Basic-Configuration-Deployment-Guide-X8-8.pdf

"You must enter the FQDN of the Expressway-E, as it is seen from outside the network, as the peer address on the Expressway-C's secure traversal zone. The reason for this is that in static NAT mode, the Expressway-E requests that incoming signaling and media traffic should be sent to its external FQDN, rather than its private name.This also means that the external firewall must allow traffic from the Expressway-C to the Expressway-E's external FQDN. This is known as NAT reflection, and may not be supported by all types of firewalls."

You should use FQDN for everything, these FQDNs therefore also need to be in the certs.  Don't mix and match hostname and FQDN - you need to be exact.  It's generally considered bad practice to have IP addresses in certs anyway.

If you've uploaded CA signed certs it's probably worth deleting the temporary default ones to ensure you don't get them cropping up in the error log like in your screenshot.

Good luck..!

Adam

[VCsupport17]

Hi Adam,

Thank you for your comment.

So the Expressway Core internal DNS should resolve the Expressway Edge FQDN? 

And on the firewall, the Expressway Core should communicate to the external IP address of the Expressway Edge?

Thank you.

[Adam Miles · Accepted solution]

No probs, it's about time I started giving back to the community! :)

Correct, with single NIC both your internal and external DNS entries for Expressway Edge need to resolve to your external IP address.

Your firewall then needs to perform NAT reflection so when Expressway Core communicates with Edge it doesn't go up to your ISP but instead stays internal.

If you had dual NIC for Edge then internal DNS for Edge would point to internal private IP (inside NIC) so therefore avoiding complexity around NAT reflection.  I much prefer this scenario and it makes troubleshooting easier as you can view packet captures from both NICs. 

Adam

[VCsupport17]

Hi Adam,

We have enabled dual NIC on Expressway Edge so the internal IP of Edge will communicate to Core.

On the Expressway Core traversal client zone, what will be the peer address? The internal IP address of Edge or the FQDN?

Do we need to create FQDN on the internal DNS and resolve the internal IP address of Edge to be able to communicate with Core?

[Adam Miles]

The peer address on Core should be the FQDN of Edge.  Internal DNS then needs to provide the DMZ internal/inside/private IP address for Expressway Edge.

For clarify the DMZ external/outside/public IP address is the one that has the associated externally facing NAT'd IP.

[VCsupport17]

Hi Adam,

Thank you for your reply.

So it means aside from the external FQDN of Edge that resolves its External IP on the public DNS, we need to create FQDN also on the internal that will resolve its internal IP of the Edge? Is it required to have the same FQDN on internal and extenal?

Thank you.

[Adam Miles]

Correct, same FQDN internal and out but different IP.

It certainly makes it simpler on your security certificates, but I guess you could use a different FQDN - you just need to make sure it's added as a SAN in the cert before you generate the CSR.  Completely untested though, so I'd suggest using same FQDN.

[VCsupport17]

Thank you Adam for the clear explanation. 

Appreciate for your help.