{"id":54,"date":"2008-07-30T14:09:06","date_gmt":"2008-07-30T14:09:06","guid":{"rendered":"https:\/\/fir3netwp.gmsrrpobkbd.com\/2008\/07\/30\/client-vs-server-side-nat\/"},"modified":"2023-02-04T09:12:24","modified_gmt":"2023-02-04T09:12:24","slug":"client-vs-server-side-nat","status":"publish","type":"post","link":"https:\/\/www.fir3net.com\/Firewalls\/Checkpoint\/client-vs-server-side-nat.html","title":{"rendered":"Check Point – Client vs Server Side NAT"},"content":{"rendered":"
Client and Server side NAT relates to when we perform destination NAT`ing.
\nThe “Translate destination on Server side” option is an legacy option which was included due to pre NG versions of checkpoint using Server-Side NAT.<\/p>\n
Client Side NAT<\/strong> – The destination address is NAT`d by the inbound Kernel <\/p>\n <\/p>\n Note<\/strong><\/em> : Source NAT always happens on the Outbound Kernel. Well when we use client side NAT the IP address is NAT`d before it hits the routing table. So we can route the packet based on the real IP. To explain things a little easier have a look at the diagram below,<\/p>\n <\/p>\n
\nServer Side NAT<\/strong> – The destination address is NAT`d by the outbound Kernel<\/p>\n
\nNote<\/em><\/strong> : Rule > NAT – The kernels will\u00a0 always process the rules before the NAT.<\/p>\nSo why does this matter ?<\/strong><\/h3>\n
\nBut when we use Server side NAT the IP is NAT`d after passing the routing table so there has to be a route for NAT`d (fake) IP in the routing table so that the operating system can pass the packet to the correct interface.<\/p>\n