Wireless Access

Hi,

here's the following challenge.  We have a MM and two mobility controllers (MC) at HQ.  Goal : have a MC at a remote site (or vessel) which gets it's license pool and config from the MM.

Sites and vessels are connected to HQ via Checkpoint (CP) vpn.

Here's the thing...  To realise this udp port 4500 is needed.  But this is being used in CP itself for the vpn (it's basically part of the vpn community which has been setup).  Meaning any packet going towards the MM private ip udp port 4500 is dropped.

The only way around this would be to use a public ip on the MM, so the MC at the remote site contacts the MM via udp 4500 that way.  

Has anyone encountered the same issue and implemented this?  I would not stamp this as best practice.  But it's this or nothing...  Or maybe Central is another solution.  No idea yet.  Security wise, trafic is encrypted.  Basically we already use this for rap communication.  And i don't want to tunnel anything to HQ.  All i need for the MC at the remote site is the license pool and config.

Check here for a similar issue. This person moved the NAT for the controller from the gateway IP to another IP to solve the issue. If you don't have another IP it may be useful to contact Check Point if you can do nat for UDP/4500 on your Check Point gateway without the gw itself processing the packet. I'm too long out of Check Point and don't have equipment to test with.

Hi Herman,

this would imply we have an additional public ip on every remote site or vessel, which is not the case.  Could probably be fixed but not sure if this is even needed.

MC on remote sites initiates an udp port 4500 session to the public ip of the MM.  This is allowed by Checkpoint because it is out of the vpn community.  I'm pretty sure this will be working.

But other caveats (maybe security related)?  I would be surprised we're the only one facing this issue?

As I mentioned in the other thread, I have seen in the far past that a Check Point gateway when it sees udp/4500 it will automatically decapsulate it into IPSec/IKE packets; which probably had to do with the built-in VPN functionality. If I remember correctly I solved it by creating a new service in Check Point on udp/4500 that and disable all inspection on that service. Then if you make sure the rulebase triggers specific on that service, the firewall left the packet alone and it started working.

Can you work with Check Point support and see what happens in the firewall? I'd say the solution is inside your firewall.

Hi Herman,

we will verify!  Thx!