- CheckMates
- :
- Products
- :
- General Topics
- :
- Peer sent wrong DN
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Peer sent wrong DN
Hi
I got a route based VPN between 1575 SMB and a 6500 gateways.
On Smartconsole it looks like this:
Where the SMB that got the problem is test7
On Smartevent monitor test7 is waiting:
The problem began immediately after upgrading the SMS to take 76.
What’s odd is that the tunnel is still functioning correctly. On the other side, there’s a Cisco AP that connects to its WLC on my side without any issues!
I checked sic_info.elg on SMB I could see this log:
CLIENT; process: fw; my port: 42545; peer port: 18191; my ip addr: 192.168.7.10; peer ip addr: x.x.x.x; sic service type: EntitlementManager; fwasync state: SIC_CLIENT_GET_SICNAME; error id: 111; SIC Error for EntitlementManager: Peer sent wrong DN: CN=fw01,O=xxxx.xxxx.xxxx.xxxxxx
On 6500 cluster object the CN=fwcl
I wonder why the SMB is getting CN=fw01, where fw01 is a gateway on fwcl cluster!
How to import the correct certificate to the SMB, is it "Reinitialize Trusted communication"?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What should i look at? The SMB is already centrally managed?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think this is a known limitation:
SmartView Monitor | ||
SMBGWY-2525 |
The SmartConsole "Device & License Information" window shows incorrect information for the Centrally Managed Quantum Spark Gateway in these scenarios:
To get to this window:
|
If you like this post please give a thumbs up(kudo)! 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Have you tried rebooting that SMB gateway?
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yes, same !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
But you say the tunnel shows as up? Both phase 1 and 2? Is the traffic through it working?
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No, the tunnel doesn't appear as up, as shown in the images above, but it is functioning correctly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So where is it failing? Phase 2?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
cpca_client lscert -dn "CN=fwcl"
cpca_client lscert -dn "CN=fw01"
Upon reviewing the 6500 certificates, I discovered the following:
- CN=fw01: This certificate is valid until 2028.
- CN=fwcl: This certificate is currently listed in the gateway VPN repository.
The issue is that the VPN peers are receiving the DN CN=fw01 certificate instead of the DN CN=fwcl certificate.
Question: Why is the VPN peer receiving the CN=fw01 certificate instead of the CN=fwcl?
