Fortigate and checkpoint IPSEC VPN

[claumakurumure]

Good day, We have setup an IPSEC VPN between Checkpoint units and Fortigate with multiple subnet. I have managed to setup commnications for tunnels using private ranges but those with public ranges are not working. I believe this is a Configuration issue The checkpoint administrator on the otherside has told me that checkpoint will only accept packets from one IP address x.x.x.x - which is the public IP address of the Forigate. Please help me to configure this or a document for this scenario. Other VPNs are working without problem. Thanks and Regards clau

[rwpatterson]

Have you tried separating the public IP ranges into a second policy and using a NAT pool?

[claumakurumure]

Hi there, I have attached a sketch network diagram ip info is not real but if you can use this to hel me do this NAT. Thank you

[rwpatterson]

What I am suggesting is that you take the 10.0.0.0, 172.0.0.0 and 192.168.0.0 networks, put them into a policy (or leave them where they are). Then take the remaining (public) networks, place them into a separate policy and use an IP pool for the outgoing traffic. For the pool, use an address range in the private area that works. All traffic going over the tunnel would then be " private" .

[claumakurumure]

hi, I have no control over the clients behind checkpoints. The clients behind the Checkpoint firewalls are public and I have configured clients Fortigate to be private. However the Check point admin requires the following 1. all communications in the tunnel should come from the public IP address of the Fortigate 2. NAT should be enabled - I am not sure where NAt Traversal or in the firewall policy So how to I put an IP pool now on the fortigate side? all my clients have private IPs and only communicate using my public IP over the tunnel When we were testing I Natted on the firewall poly but it did not work - even tried to disable and enable NAT travesal but no luck.

[#6]

have you tried enabling outbound nat on your vpn policies for the checkpoint? this will make the traffic come from one ip address, your external interface.

[severach]

I have managed to setup commnications for tunnels using private ranges but those with public ranges are not working.

Any router that supports VPN easily handles private IP to private IP tunnels that do not overlap. You won' t find a router anywhere that can match the Fortigate at handling overlapping subnets and mapping to public IPs. The implementation and instructions could be better it' s the least crappy available.

Other VPNs are working without problem.

You mean VPN' s with other companies that do not NAT are working without problems. If a company asks for you to NAT any addresses then they want them all NAT. You should wonder why if their router is so good then why can' t they do the NAT on their end?

1. all communications in the tunnel should come from the public IP address of the Fortigate

You dropped a word. Even if that' s what they said that' s not what they want. They want all communications to come from the public IP address range of the Fortigate. You generally don' t map any private IP to the actual public address of the router to avoid routing problems for the other peer' s network. You have two problems. They don' t know what they' ve asked for and you don' t either. It' s a simple translation of what they, BIG Incorporated, have done and they assume you must do the same thing because they think your router is as incapable as theirs. Perhaps BIG has purchased some /24 netblocks so they own addresses 2.2.2.1-255 for one division and 41.3.3.1-255 for another division. They set their public IP of their checkpoints to 2.2.2.2 and 41.3.3.3. All the rest of the addresses are available for NATting because they think they need to own the addresses to NAT to them. Some routers like Cisco require the NAT IPs to be owned because NAT over IPSec is incorrectly implemented. You, SMALL Incorporated, may have only purchased a single static IP: 6.6.6.6 though you are more likely to have purchased a /29 netblock which would mean you actually own 6.6.6.0-7. The gateway consumes the second address 6.6.6.1 and the router consumes one, preferably on the top or the bottom, so the rest are available for NAT, or so it would seem. BIG is expecting you to NAT whatever private IPs you are providing to the available public IPs and expects you to buy as many public IPs as necessary to NAT all of the machines they need to interface to. They wouldn' t ask that if they had ever used a router that implemented NAT over IPSec correctly. I' ll show an example with some randomly chosen internal addresses of computers and printers where all public IPs are used up: ?: 6.6.6.0 Gateway: 6.6.6.1 10.0.2.54 natip 6.6.6.2 10.0.4.11 natip 6.6.6.3 10.0.3.18 natip 6.6.6.4 10.0.2.11 natip 6.6.6.5 Fortigate: 6.6.6.6 10.0.2.1 natip 6.6.6.7 Having the router in the middle is a routing disaster for the other peer' s network. Either move the Fortigate to one of the ends or forget about NATing to 6.6.6.7. Use it for something else. BIG only wants to communicate to a 6.6.6.x address because that, like all Internet addresses, is already routed in their network to their VPN router and they don' t want VPN peers like you dropping random subnets they can' t administer into their network. >The checkpoint administrator on the otherside has told me that checkpoint will only accept packets from one IP address x.x.x.x - which is the public IP address of the Forigate. This tells me that the other admin does not understand VPN. All VPN already work this way and they do not work any other way. No matter what addresses are chosen, public or private, the only communication that ever occurs over the Internet is between the public IPs of the two peers. 6.6.6.6 ↔ 2.2.2.2 6.6.6.6 ↔ 41.3.3.3 The Internet never sees any communication from 10.0.2.54 or 6.6.6.2. That only happens inside the private networks. >I am not sure where NAt Traversal or in the firewall policy NAT is not similar to NAT Traversal. NAT which for you is NAT over IPSec changes the source or destination addresses as the packet passes through the VPN. NAT Traversal is used when either VPN peer is not on the edge. If you or the other network has another router in front of the VPN router then NAT Traversal is needed. If you were expecting IPSec connections from a client inside a hotel you would need NAT Traversal enabled to pass through the hotel router. If your phase 1 connects then you don' t need NAT Traversal. Policy tunnels are easier to make and NAT is more straightforward than with interface tunnels so start with a policy tunnel. Read the section in the FortiOS VPN documentation about Overlapping Subnets. You' ll be doing that but only on one side. Create a phase 2 in the GUI ph2BIG: 6.6.6.2 ↔ 2.2.2.2/28 Create a policy in the GUI 110: 10.0.2.54 ↔ 2.2.2.2/28 The policy does not match the phase 2 so you might be thinking that you have an orphaned phase 2. These CLI commands that enable the NAT are what connect the phase 2 to the policy:

config firewall policy
 edit 110
 #set natinbound enable
 set natoutbound enable
 set natip 6.6.6.2 255.255.255.255
 end
 
 config vpn ipsec phase2
 edit " ph2BIG" 
 set use-natip disable
 next
 end

As the packet from 10.0.2.54 passes through the VPN it will be NAT to 6.6.6.2. Returning packets to 6.6.6.2 will be NAT back to 10.0.2.54 before appearing on your network. Create additional policies with natip and tunnels as needed. Sometimes Inbound NAT makes tunnels work properly if something is incorrectly configured. Fix the problem so the tunnel works with or without Inbound NAT. Having to NAT each address is a hassle. It would be much better to rearrange your network a bit. ?: 6.6.6.0 Gateway: 6.6.6.1 Fortigate: 6.6.6.2 10.0.2.3 natip 6.6.6.3 10.0.2.4 natip 6.6.6.4 10.0.2.5 natip 6.6.6.5 10.0.2.6 natip 6.6.6.6 10.0.2.7 natip 6.6.6.7 Create a phase 2 in the GUI ph2BIG: 6.6.6.0/24 ↔ 2.2.2.2/28 Create a policy in the GUI 110: 10.0.2.0/24 ↔ 2.2.2.2/28 In the CLI:

config firewall policy
 edit 110
 #set natinbound enable
 set natoutbound enable
 set natip 6.6.6.0 255.255.255.0
 end
 
 config vpn ipsec phase2
 edit " ph2BIG" 
 set use-natip disable
 next
 end

All done with a single tunnel and policy. Your main challenge will be getting the admins of the Chokepoints to match your phase 2. Checkpoints are so complicated that few admins know how to configure them. Often a call to Checkpoint support will be necessary and they can since Checkpoints do not function without an active support contract. The NAT is larger than it first appears. Since source NAT over IPSec is implemented properly on the Fortigate you can NAT to public IP addresses you don' t own. Even though you only own 6.6.6.0-7, this tunnel and policy is already NATing: 10.0.2.2-254 natip 6.6.6.2-254 These addresses are already accessible. So when BIG has run you out of owned public addresses, no problem, SMALL has an unlimited number of public IP addresses to use because SMALL' s Fortigate router implements NAT over IPSec correctly. Even if you have only bought a single static IP you still have an unlimited number of public IP addresses to use. The only addresses you can' t use are those that are already being used by one of BIG' s other peers. The next step is to do this with interface tunnels.