Client behind another security gateway while connecting gives certificate not valid error

[Hughes]

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

[PhoneBoy]

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?

[Hughes]

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. 

[Hughes]

Also, if the client is running on a mobile hotspot, then everything works fine and there is no client certificate error

[PhoneBoy]

A TAC case is probably in order here.
I have a feeling the SMB appliance is injecting it's own certificate here. 

[Hughes]

Thanks. Yes. I have opened a case with TAC. Will keep the forum posted once they find a solution

[Hughes · Accepted solution]

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

[the_rock]

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

[Hughes]

Thanks. I tried running the zdebug just as you have suggested. I see no drops