| CPUG | |
| The Check Point User Group | |
| A Resource For The Check Point Community. Fast. Useful. Independent. | |
|
| |||||||
![]() |
| | LinkBack | Thread Tools | Display Modes |
| |||
| This is a strange one. Not sure if it belongs in the NAT group, SecureClient group, or a little of both. Anyway, I'm looking for some pointers on how I can handle the situation below. When users are on the company's local network, they access an externally hosted app (say, 99.99.99.99) through a site-to-site VPN. All internal resources are HIDE NATted to one public address, say 1.1.1.1. Works fine. Note: the app is only accessible through the site-to-site VPN. When these users are working remotely and they connect SecureClient with Office Mode, they want to access the external app. I can't put the app's addr in the encrypt domain, or the site-to-site won't work. I think the only way to do this is with some fancy natting: statically nat 99.99.99.99 to x.x.x.x, put x.x.x.x in the encrypt domain. Remote user accesses x.x.x.x, session comes through SecureClient VPN, hits firewall, dest is natted to 99.99.99.99, source is natted to 1.1.1.1, session goes out over site-to-site VPN tunnel. Will this even work? Has anyone done it successfully? Is there a better way? We do not use automatic NAT; is that required to do this sort of double natting? |
| |||
| Hi Chris, Do you disabled the nat inside this vpn community? If nat is enabled on your community, although I'm not sure you can try to hide nat the office mode IP pool and mark the route all traffic through the gateway on your profile settings. My second suggestion is that if you have a DHCP server on your local network, give the client IP addresses from DHCP server. Use the same pool with your local network. Regards... |
| |||
| There is something you can try. Edit your firewall properties, go to the "Remote Access" tab. If you can check the Hub Mode Configuration, that means that all traffic will be forced down to the firewall. This would mean that traffic to the 99.99.99.99 server would also come through the client-to-site VPN. From there it would go back into the site-to-site VPN. You would need to NAT the SR connections with the Hide NAT too, so you might need to change your NAT rule to be: Internal+IP pool | 99.99.99.99 | any | Hide IP | = | = Important note: Hub mode means all SR traffic comes to the firewall, it may not be ideal for you... this means they will access the web via the firewall, etc. If that isn't acceptable, then you can do the NAT thing you mention. |
| |||
| Thanks for your responses. We are using Traditional VPNs, not communities. Routing all traffic through the tunnel is not an option. We are using DHCP to allocate Office Mode IP addresses in the 10.x.x.x range to our SecureClient VPN users. So in effect our NAT rule needs to be: VPN-Pool-10.x.x.x | nat-Dest-IP | nat-Src-IP (hide) | real-Dest-IP (static) Is this method of double NATting possible? Should it work? |
| |||
| Yes it is possible, yes it should work. The only thing that you need to make sure is that the firewall routes the packet correctly, but I don't see that being an issue with translate on client side. If it doesn't work, try adding routing from nat-Dest-IP to real-Dest-IP. |
![]() |
| Thread Tools | |
| Display Modes | |
| |