- CheckMates
- :
- Products
- :
- Quantum
- :
- Remote Access VPN
- :
- Client behind another security gateway while conne...
- 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
Client behind another security gateway while connecting gives certificate not valid error
In my setup, I have a security gateway in a main location which handles all the remote VPN access connections. I also have a satellite office that has a security gateway that has multiple VLANs connected to it. While the administrative VLAN has site-to-site VPN defined to the main location security gateway, the other VLANs are not part of the site-to-site VPN. When users in the other VLANs try to use the Windows Capsule client to do Remote Access VPN, they get "Connection Failed: Certificate not valid" error. We use certificate based authentication. If the same users try this from any other internet connection (including their mobile hotspots), everything works fine. What could be wrong?
Any clue will greatly help.
Thanks in advance,
Krishna
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Finally after opening a TAC case we resolved the issue. After doing a series of debug sessions, the TAC team identified that the SMB device was translating the IP of the client requesting for the VPN connection to its own public IP and also inserting its own certificate. This would fail the client certificate authentication. TAC suggested to add a NAT rule that keeps the original address of the client when the VPN is initiated to the central GW's public IP. This resolved the issue
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is HTTPS Inspection enabled?
What do you see in the logs for either gateway when a client tries to access?
What version/JHF are the gateways?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks. HTTPS inspection was originally enabled. I turned it off. No change in status. On the logs of the main location, I see https packets from the satellite office GW (source IP is public IP of the satellite office GW) with the site-site community. On the logs of the remote firewall (satellite office), I see IKE_NAT_Traversal packets on UDP port 4500 and https packets destined to the central firewall. Here the source IP is the client's internal IP and the community is again site-site. The satellite office GW is SMB 1400 running R77.20.87 (990171302) and the central firewall is running 80.30 JHF Take 219.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Also, if the client is running on a mobile hotspot, then everything works fine and there is no client certificate error
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A TAC case is probably in order here.
I have a feeling the SMB appliance is injecting it's own certificate here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks. Yes. I have opened a case with TAC. Will keep the forum posted once they find a solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Finally after opening a TAC case we resolved the issue. After doing a series of debug sessions, the TAC team identified that the SMB device was translating the IP of the client requesting for the VPN connection to its own public IP and also inserting its own certificate. This would fail the client certificate authentication. TAC suggested to add a NAT rule that keeps the original address of the client when the VPN is initiated to the central GW's public IP. This resolved the issue
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you maybe run simple zdebug on the firewall when this is about to happen and grep for specific user? For example fw ctl zdebug + drop | grep user1 (or whatever the username would be) and then do the test and observe the output.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks. I tried running the zdebug just as you have suggested. I see no drops