Office Mode IP routing

[NorthernNetGuy]

I'm having a problem with reaching my VPN clients from our internal network. They can ping internal resources when they are connected on VPN, but I can't ping those clients from our internal network. Our VPN clients are using Office Mode IPs. They can access the required internal resources just fine. but us being able to administer our PCs on VPN is hampered. 

I can see my internal traffic on the firewall logs going to the office mode IP client with a Decrypt action.

I've seen some forum posts with suggestions of adding some NATing rules, but haven't succeeded with these suggestions :https://www.cpug.org/forums/archive/index.php/t-22041.html

I've noticed I have a static route defined on gaia that has the destination address of the Office Mode subnet to point to our public IP gateway. This was a route that was ported over from our old TMG deployment and it's VPN client. I'm wondering if this might be causing the issue, or unrelated. I don't see anything on the checkpoint side of needing to define a static route for the Office mode IPs.

Any suggestions are appreciated!

[PhoneBoy]

If you run tcpdump or fw monitor on the gateway when you try to connect to the Office Mode IP, what do you see?
Anything in the logs that might provide some guidance?
You definitely need access rules that allow access to the Office Mode IPs.

[Timothy_Hall]

Make sure the addresses you are assigning from the Office Mode pool do not fall within the firewall's defined encryption domain (or the specific domain defined for Remote Access if you are using that).

Not sure if this setting applies any more, but under Global Properties...Remote Access try enabling "Enable back connections (from gateway to client)" if not already set.

Also make sure that traffic initiated from the inside network to the Office Mode IP addresses is not being NATted; you may need a manual anti-NAT rule added for this type of traffic.

As Dameon said you also need an explicit rule in your Firewall/Network policy layer allowing this traffic.

[NorthernNetGuy]

I already had enabled the 'Enable back connections' option already, as well as created a manual NAT rule to not NAT the traffic to the office mode IP, as well as created a policy rule to allow traffic from internal to the office mode.

My thoughts are that the static route I have defined for the office mode IP could be causing the issue.

I'll capture some traffic and see what I get.

[Timothy_Hall]

Sounds like you have everything configured correctly on the Check Point end of things, probably some kind of routing issue that a packet capture should help reveal.

[NorthernNetGuy]

I've tried a few different captures, but i'm not sure if I'm seeing the problem.

Tried doing the following commands, but I don't see the address get translated out of the officemode IP to the external IP of the VPN client. 

here's a few of the types I tried

internal host:

fw monitor -e "accept host(10.110.12.30) and tracert;"

Internal host or vpn client external ip:

fw monitor -e "accept host(10.110.12.30) or host(<VPN client external IP>) and tracert;"

internal host or business IP:

fw monitor -e "accept host(10.110.12.30) or host (10.231.15.15) and tracert;"

Business IP host

fw monitor -e "accept host (10.231.15.15);"

I'm wondering if it's using the static route for the business IP prior to translating it back to the clients IP