Category Archives: Pulse Secure
Articles on Juniper & Pulse secure SA & MAG Devices when running Pulse Secure Access Service
Juniper SA to MAG Upgrade Guide
Juniper MAG/SA Cluster Ports
Summary:This article provides information about the ports that maintain the cluster state and the importance of ARP.
Problem or Goal:Information about the ports that maintain the cluster state and the importance of ARP.
Solution:There are several KB articles, which list all the ports that are involved with SA/UAC clusters. However, at times, it is required to specifically know which ports maintain the cluster state.
The ports that are responsible for maintaining the cluster state are:
- ARPAt times, this protocol is forgotten during cluster state checks/investigations. The ARP requests/replies are important to a SA cluster, as ARP’s are sent to the gateway of the subnet, to which the VIP of the cluster belongs, to maintain reach-ability to the subnet gateway.
- UDP 4803The state data replication, which refers to all data that must be replicated between cluster nodes. Examples include a user session record, when session synchronization has been enabled between cluster members (see the UI cluster properties page) and the cluster-wide configuration.
- UDP 4804 – Heartbeat.
You should always check the ARP tables, when investigating/checking a cluster state, along with the other two ports listed above; as all the above ports are important for maintaining a cluster state.
What TCP and UDP ports are required/used for clustering and what is each port used for?
Port Number |
Usage |
Encrypted |
| TCP 4808 | Cluster heartbeats and intra cluster RPC calls | Yes |
| TCP 4809 | Clustering on. Used to query the build version being run at the remote IVE | No |
| TCP 4900-4910 | For a short period when a node joins the cluster Key exchange for group communication, state sync where applicableMostly copying the state data from one cluster node to another when a node joins the cluster or when a cluster rejoins after partition. There should be significant data only on one these ports | Yes |
| UDP 4803 | Clustering On, always Group communication. Incremental state data replication. | Yes |
| UDP 4804 | Clustering On, always Token Heartbeat. Group communication heartbeats. No data on this channel. | No |
Juniper Secure Access: Using TCP Dump to View Cipher Information
Using TCP Dump to View Cipher Information
You can use the TCP Dump tool to view which cipher each client uses to connect to the server. TCP Dump is a packet analyzer that intercepts (sniffs) and displays TCP/IP and other packets transmitted or received between the server and clients.
 |
Note: To permit debugging, it is recommended that the ECC certificate be replaced by an RSA certificate so that an RSA cipher suite gets selected and then the application data can be decoded. |
To capture packet headers:
- Select Maintenance > Troubleshooting > Tools > TCP Dump.
- Select the interface, internal or external or both, you wish to sniff and then the VLAN port.
- Click Start Sniffing.The next time a user points a browser window to the server or logs in to the server, handshake information is obtained.
- Click Stop Sniffing when done.
To view the packet headers:
- Select Maintenance > Troubleshooting > Tools > TCP Dump.
- Under Dump file, select SSLDump from the file menu and the certificate to use. See Figure 1.
Figure 1: Viewing the TCP Dump Output
The certificate names in the TCP Dump window are the same as the “Certificate issued to” names in the Device Certificates window. Select the certificate corresponding to the port you wish to view packet information. See Figure 2.
Figure 2: Issued to Certificate on the Device Certificates Pages
- Click Get.
Portions of a TCP dump output follow.
The client starts a handshake with the server:
1 1 0.0007 (0.0007) C>S Handshake
The client then lists its supported cipher suites:
cipher suites
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_SHA
TLS_ECDH_ECDSA_WITH_DES_CBC3_SHA
...
The server acknowledges the handshake:
1 2 0.0010 (0.0003) S>C Handshake
The server compares the cipher suites on the client with the ones on the server and picks the cipher suite that is preferred by the server based on SSL options:
cipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
Example TCP Dump Output
New TCP connection #1: 10.64.8.3(46200) <-> 10.64.90.21(443)
1 1 0.0007 (0.0007) C>S Handshake
ClientHello
Version 3.3
cipher suites
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_SHA
TLS_ECDH_ECDSA_WITH_DES_CBC3_SHA
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_SHA
TLS_ECDH_ECDSA_WITH_RC4_SHA
Unknown value 0xc001
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
compression methods
NULL
ClientHello Extensions [113]=
00 6f 00 0b 00 04 03 00 01 02 00 0a 00 34 00 32
00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09 00 0a
00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 04
00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 10
00 11 00 23 00 00 00 0d 00 22 00 20 06 01 06 02
06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 01
03 02 03 03 02 01 02 02 02 03 01 01 00 0f 00 01
01
1 2 0.0010 (0.0003) S>C Handshake
ServerHello
Version 3.3
session_id[32]=
a3 07 40 6e 73 12 c2 4d f3 7d b9 77 f8 97 e1 94
fc 1b 51 6a 66 3c 99 d6 c7 7d 0e fa 29 2e d0 c4
cipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
compressionMethod NULL
ServerHello Extensions [20]=
00 12 ff 01 00 01 00 00 0b 00 04 03 00 01 02 00
0f 00 01 01
1 3 0.0010 (0.0000) S>C Handshake
Certificate
1 4 0.0010 (0.0000) S>C Handshake
ServerHelloDone
1 5 0.1413 (0.1403) C>S Handshake
ClientKeyExchange
1 6 0.1413 (0.0000) C>S ChangeCipherSpec
1 7 0.1413 (0.0000) C>S Handshake
1 8 0.1464 (0.0051) S>C ChangeCipherSpec
1 9 0.1464 (0.0000) S>C Handshake
1 10 9.2389 (9.0924) C>S application_data
1 11 9.5828 (0.3438) C>S application_data
1 12 9.5833 (0.0004) S>C application_data
1 9.5833 (0.0000) S>C TCP FIN
1 13 9.5999 (0.0166) C>S Alert
1 9.5999 (0.0000) C>S TCP FIN