ScreenOS Certificates

I implemented a public SSL certificate on a Netscreen today, it was a little tricky to get the CA (Comodo) to accept the CSR generated from the web interface of the Netscreen. The problem was that the Netscreen inserts multiple CN= attributes into the request. the CA is only expecting to see one, which is the domain name for the certificate.

XYZ-SSG140-Cluster:Hostname-XYZ-ACT(M)-> get pki x509 dn

Hostname-XYZ-ACT's X509 Distinguish Name:
CN=0165072008070226

CN=domain.example.org

CN=0044 20 1234 5678

CN=rsa-key

CN=admin@example.org

CN=Root

C =GB

O =Example Company Ltd

The fix for this is to enable the raw common name command which tells the Netscreen to only use the domain name for the CN attribute.

set pki x509 raw-cn enable

Now we get the following output from the get pki x509 dn command:

XYZ-SSG140-Cluster:Hostname-XYZ-ACT(M)-> get pki x509 dn

Note: *** Raw CN mode enabled ***

CN=domain.example.org

C =GB

O =Example Company Ltd

So to recap - the full commands to generate the certificate areset pki x509 raw-cn enable

set pki x509 dn country-name "GB"
set pki x509 dn org-name "Example Company Ltd"
set pki x509 dn org-unit-name "Testing"
set pki x509 dn email "admin@example.org"
set pki x509 cert-fqdn domain.example.org

exec pki rsa new-key 1024

This will output the CSR, it will look something like this, you need to copy everything including the BEGIN and END REQUEST statements and give that to your CA.

-----BEGIN CERTIFICATE REQUEST-----
MIIB0zjCCATsCAQAwZTENMAsGaA1UEChMESk5QUjEZMB
cGA1UEAxMQMDsA0MzAyMjAwMjAwMDE4NjEQMA4GA1UE
AxMHcnNhLWtleTEYMBYGA1UEAxMPd3d3Lmp1b
-----END CERTIFICATE REQUEST-----

Cisco ASA Deny TCP (no connection)

I came across an interesting problem today in dealing with an asymmetrical routing issue with a Cisco ASA. The network is set up as follows:

I encountered the issue when trying to manage the access points and switches across the site-to-site VPN from the management workstation. All devices have their default gateway pointed at the ASA, and the ASA has a route to the remote network via the device handing the site-to-site VPN - in this case a netscreen SSG5 firewall. Ping's work fine, however when trying to SSH or telnet to the devices a connection is not made.

Breaking down the traffic path, the management traffic is leaving the workstation, being encrypted across the tunnel and then hitting the end device, the return path however is sending traffic to the ASA. I had enabled the command same-security-traffic permit intra-interface on the ASA to permit traffic to pass out the same interface that it comes in, however I still found that I was not getting a response from the device.

After enabling some logging on the ASA it was clear the the ASA was denying the traffic, the following was logged:

%ASA-6-106015: Deny TCP (no connection) from 192.168.1.230/22 to 10.0.1.86/4060 flags SYN ACK on interface inside

The ASA is basically denying the traffic, due to not seeing the initial SYN packet traverse through itself, so it's being a good stateful firewall. After a bit of googling and head scratching - it doesn't appear that there is a way to tell the ASA to permit this traffic, so a workaround is in order.

didn't fancy adding static routes onto each device to point to the remote network via the SSG, in fact the 1131G access points in question do not support the ability to add an independent route. The solution I came up with was to have the SSG forward traffic via the ASA, forcing the ASA to see the whole conversation and thus permit traffic back across the VPN. This was achieved by adding /32 host routes to each device on the SSG via the ASA.