Office Mode and Multiple sites

[Thorpuse]

Hi All,

I'm looking to get some thoughts or comments from people who use Office Mode on Multiple Sites. I have an environment where SecuRemote users need to access multiple sites. However, SecureClient only allocates OM addresses to the *first* site it connects to, and as such the connection to second and third sites do not get allocated an OM address without having to disconnect from Site 1.

Apart from the rather obvious feature request to Check Point on this, how have other people dealt with this issue? I suppose one solution is to use the same OM range on all sites, but that requires some messy routing when the sites are connected by private WANs. The solution I've been trying to use so far is to set IP Pool NAT ranges on all sites, so that the OM connection should fall back to using IP Pool NAT regardless. This appears to work, except when site 1 and site 2 have OM turned on, and the user has already connected to Site 1. Then, Site 2 either uses its raw IP or the OM address, and ignores pool NAT (which, to me, is a weird result....). For an unrelated, but to be disclosed reason, I'm uncomfortable using IP Pool NAT in this way as well....

Happy to hear anyone else's experiences and suggestions on this.

Thanks,

[RayPesek]

Why do they need to connect to multiple sites if they are all connected by the WAN? Or maybe not all are interconnected?

If they are, you can enable Hub Mode and have them connect to just one site. Use desktop policies to enforce who can go where.

If the sites are not all WAN-connected, is there a danger that they would become interconnected via the SecureClient connection if connections were allowed to both sites at the same time?

Ray

[Thorpuse]

Hi Ray,

Fair questions - the Internal WAN has limited bandwidth, so the intention is to go direct to the relevant site where possible over internet links. The encryption domain of each site is unique, so that determines the routing traffic.

I'm reluctant to use Hub mode, because of the bandwidth penalty in and out, and I'm trying to avoid pushing all traffic through a single gateway. That is an option though, and I may have to consider it.

My biggest issue with Interconnection is more the fact that "Proper Subset" MEP is not supported in SecuRemote. And CP only supports one Remote Access community. Can't tell you how much that annoys me now....

I started looking at the "OM per-site" setup - it seems to be similar to what I'm trying to achieve, but the documentation is incredibly vague about the details. Anyone used this and can provide a better explanation, partiucularly around whether multiple OM ranges are required and if not, how it deals with conflicts?

Thanks,

[melipla]

One way to address this would be to define OM ranges for each gateway in the Remote Access community and then use a Remote Access MEP [each gateway would need to be NGX for this to work]. That would mean the client only has to connect to one gateway but does add additional vpn traffic between gateways which it sounds like you don't want to do.

Another would be to define OM ranges for each gateway in the Remote Access community and "Use first allocated Office Mode IP Address for all connections to the Gateways of the site". SecureClient needs to be R60 (or higher) and the gateways in the RA Community need to be R60 or higher in order for the "use the first allocated OM IP" to work properly. The client will set up a tunnel with each gateway in the community [if it attempts to access their encryption domains] but it would use the OM IP from the first gateway it connected to.

It sounds like the second one is similar to what you're doing now / want to do, only its not one OM Pool for all the gateways which should simplify routing.

PS I complete agree, the SecureClient section of the VPN AdminGuide needs to be majorly updated.

[Thorpuse]

Originally Posted by melipla

Another would be to define OM ranges for each gateway in the Remote Access community and "Use first allocated Office Mode IP Address for all connections to the Gateways of the site". SecureClient needs to be R60 (or higher) and the gateways in the RA Community need to be R60 or higher in order for the "use the first allocated OM IP" to work properly. The client will set up a tunnel with each gateway in the community [if it attempts to access their encryption domains] but it would use the OM IP from the first gateway it connected to.

It sounds like the second one is similar to what you're doing now / want to do, only its not one OM Pool for all the gateways which should simplify routing.

I experimented with this today. It seems like the solution I'm looking for, except that with the network topology and design I'm working with (long story...) I'll need to use the same OM Range on all sites to ensure that the OM IPs for particular sites are correct (in a nutshell, the OM users need to go through back-end FWs and the rules there are IP-based, and not as easy to manage). This raises a much larger and slightly scarier concern about what would happen if (when!) the IP ranges conflict due to GW2 not knowing about GW1's IP allocations.... The other thing that worries me is that OM Per Site requires you to turn off OM Anti-Spoofing. This also has some potentially ugly circumstances....

Appreciate the comments. It's helping me build one heck of an RFE for Check Point though! There must be a simpler way....

[melipla]

Originally Posted by Thorpuse

I'll need to use the same OM Range on all sites to ensure that the OM IPs for particular sites are correct

You could accomplish this by having a particular gateway w/the appropriate OM & force users to authenticate to this gateway first. Then you can use differing OM pools on the other gateways & not worry about the OM overlap and your SecureClient users will have the proper OM IP for back-end servers.

Originally Posted by Thorpuse

The other thing that worries me is that OM Per Site requires you to turn off OM Anti-Spoofing. This also has some potentially ugly circumstances....

Yes, that is a concern, fortunately in my case I have cisco devices with ACLs which effectively replace this missing spoof check.

Originally Posted by Thorpuse

Appreciate the comments. It's helping me build one heck of an RFE for Check Point though! There must be a simpler way....

It may be painful, but in the long run it may be better to expand the back-end IPs allowed in. In all honesty I don't see CheckPoint being able to redesign it so that multiple Remote Access communities could exist. I think their focus is more about integrating products such as Pointsec and Integrity then redoing their core architecture to fix the problems associated with implementing multiple remote access communities...

[lammbo]

Originally Posted by Thorpuse

This raises a much larger and slightly scarier concern about what would happen if (when!) the IP ranges conflict due to GW2 not knowing about GW1's IP allocations....

Hmmmm.... Interesting.

For the sake of explaining this, let's say you have 4 sites. Let's also say you are going to use 172.30.192.0/22 as your OM pool network. Also for simplicity, you have Windows DHCP/DNS servers available.

What if you setup DHCP scopes at each site for this OM net and only allow 1/4 of the range's IPs to be issued by each site's DHCP server? There would be no overlap in issued addresses. Spoofing would still need to be turned off for OM, but this would eliminate your concern of IP conflict.

Yet, given all of this scenario, am I missing something here? In traditional mode, I can connect to my main Office and get an OM IP via SecureClient. But if/when I connect to another site, my OM IP is NOT recycled and used for my outbound VPN, it uses the locally assigned 192.168.1.x IP (I hate that subnet ;). So what difference would it make to even perform this trickery? Is it different in Simplified mode? Have I missed a major component to making this work?

As it is right now, I just build different VPN client install packages for each of my work sites and the users connect directly to their local firewall (i.e. Sydney to Sydney, London to London, etc.) You cannot have more than 1 site setup in SecureClient if you have any overlapping topology (ie - multiple sites managed by the same SCS are considered overlapping) and you may only have 1 site active at a time for DIRECTLY connecting. As mentioned previously though, connections to other sites just use the local IP. So the only way I get an OM IP for site X is to directly connect to site X. Switching to Site Y profile will cause Site X profile to become disabled and Site Y will give me an OM IP (from Site Y) and any connections to site X will use the local address.

[Thorpuse]

Originally Posted by lammbo

What if you setup DHCP scopes at each site for this OM net and only allow 1/4 of the range's IPs to be issued by each site's DHCP server? There would be no overlap in issued addresses. Spoofing would still need to be turned off for OM, but this would eliminate your concern of IP conflict.

This is the OM per-site solution. Key issue/problem to be addressed here is routing, because you need to ensure that the return paths point to the same gateway that the traffic came in.

Originally Posted by lammbo

Yet, given all of this scenario, am I missing something here? In traditional mode, I can connect to my main Office and get an OM IP via SecureClient. But if/when I connect to another site, my OM IP is NOT recycled and used for my outbound VPN, it uses the locally assigned 192.168.1.x IP (I hate that subnet ;). So what difference would it make to even perform this trickery? Is it different in Simplified mode? Have I missed a major component to making this work?

As it is right now, I just build different VPN client install packages for each of my work sites and the users connect directly to their local firewall (i.e. Sydney to Sydney, London to London, etc.) You cannot have more than 1 site setup in SecureClient if you have any overlapping topology (ie - multiple sites managed by the same SCS are considered overlapping) and you may only have 1 site active at a time for DIRECTLY connecting. As mentioned previously though, connections to other sites just use the local IP. So the only way I get an OM IP for site X is to directly connect to site X. Switching to Site Y profile will cause Site X profile to become disabled and Site Y will give me an OM IP (from Site Y) and any connections to site X will use the local address.

What you're missing is the need to connect to multiple sites concurrently, and still use an internal IP range on all sites. I think I've locked down my options to this -

1. Use OM per-site, and either include all OM ranges for all Sites in the access rules downstream or use a common OM pool on all sites OR
2. Get Check Point to fix what looks more and more like a bug, where if a SR User has been given an OM address by GW1, GW2 does not perform IP Pool NAT on inbound connections.

[lammbo]

I just ran into another issue with this, how ironic.

One of my sites at a recently acquired company has the dreaded 192.168.1.x LAN subnet. A user in the UK is using SecureClient and is connected to a UK firewall and has an OM IP. They are now trying to reach a web resource in the US office and has 192.168.1.103 - meanwhile, a user at the new site also has this IP and there is a site to site between. So now, the firewalls are getting confused on what traffic to route where on that IP - what a mess.

The error message in Tracker reads: "encryption failure: decrypted and user methods are not identical (VPN Error code 01)" Of course they don't match, one is a site to site and 1 is a user encrypt.

I have not re-read the entire thread today, but wqhoever said CP should 'fix' this is correct. I can't beleive it would be too much to ask if a SecureClient with OM IP could re-use the IP on other gateways in your CP domain. I don't want to use hub mode because why should a UK employee (or worse - Sydney) have to connect to my main site in the US and then be routed back across the pond again when a programmatic change could probably resolve this.

It's already 125 ms from Charleston to London, why make that trip twice for larger encrypted packets?!?

[melipla]

Originally Posted by lammbo

I can't beleive it would be too much to ask if a SecureClient with OM IP could re-use the IP on other gateways in your CP domain. I don't want to use hub mode because why should a UK employee (or worse - Sydney) have to connect to my main site in the US and then be routed back across the pond again when a programmatic change could probably resolve this.

You can do this, sounds like each Remote Access gateway you use already have their own OM pool so you merely have to enable "Use first allocated Office Mode IP Address for all connections to the Gateways of the site" and your SecureClient will reuse it's UK OM IP when communicating with your US vpn domain.

[lammbo]

Originally Posted by melipla

enable "Use first allocated Office Mode IP Address for all connections to the Gateways of the site" and your SecureClient will reuse it's UK OM IP when communicating with your US vpn domain.

Awesome! Thanks melipla, I remember seeing that long ago and never put it together with this issue (mostly because I forgot about it =-)
I really wish I had more exposure to some of this stuff in the live environment I've learned from these last 3 years. But I guess I really should just count myself lucky that I haven't had more issues of my own. Oh well, since I found the CPUG community, I have learned a great deal from the issues of others, keep it coming guys!

For reference by others in the future, the enable feature he is talking about is located here:
Global Properties -> Remote Access -> VPN Advanced -> Office Mode -> Use first allocated Office Mode IP Address for all connections to the Gateways of the site (Checkbox)

[lammbo]

Does this include sites in Traditional mode? In the Help file text below, only VPN communities are referenced.


From the Help file: (including the misspelled word dependent - LOL)
Office Mode (per site)
After a remote user connects and receives an Office Mode IP address from a gateway, every connection to that gateways encryption domain will go out with the Office Mode IP as the internal source IP. The Office Mode IP is what hosts in the encryption domain will recognize as the remote user's IP address.

The Office Mode IP address assigned by a specific gateway can be used in its own encryption domain and in neighboring encryption domains as well. The neighboring encryption domains should reside behind gateways that are members of the same VPN community as the assigning gateway. Since the remote hosts connections are dependant on the Office Mode IP address it received, should the gateway that issued the IP become unavailable, all the connections to the site will terminate.

[Thorpuse]

Hi All,

There was actually a configuration issue which I've now resolved, which gets OM and Pool NAT to play nice together again on multiple gateways. At this stage, I think this is the best solution I can run with, although the OM Per-Site idea has merit.

Still don't understand why CP hasn't or won't allow multiple OM Virtual Interfaces and/or Multiple Remote Access VPN Communities. Hopefully in NGX R70, if anyone's listening.....

[melipla]

Originally Posted by lammbo

Does this include sites in Traditional mode? In the Help file text below, only VPN communities are referenced.

Good question, we use simplified mode but I would guess that this would work in Traditional mode for NGX gateways. From what I've seen, the last bit about "should the gateway that issued the IP become unavailable, all the connections to the site will terminate." would only apply if you were using a Remote Access MEP configuration. It sounds like your Remote Access community gateway's VPN domains are not overlapping so this would not apply to you.

Originally Posted by Thorpuse

Still don't understand why CP hasn't or won't allow multiple OM Virtual Interfaces and/or Multiple Remote Access VPN Communities. Hopefully in NGX R70, if anyone's listening.....

Hmm I'm still not sold. Don't get me wrong, I've lamented that CP should have more than one Remote Access community. However, I don't see what you'd gain by having more than one.

[Thorpuse]

Originally Posted by melipla

Hmm I'm still not sold. Don't get me wrong, I've lamented that CP should have more than one Remote Access community. However, I don't see what you'd gain by having more than one.

Ummm... let me see -

1. Better control over Topology advertisements.
2. No issues/better control regarding overlapping address spaces in encryption domains. (This is the big one for me)
3. Complete control over which users can connect to which gateways.
4. Better control over Office Mode assignments (assuming that multiple OM interfaces isn't also in the RFE list.
5. No need to rely on Hub Mode/Pool NAT/OM Per-site kludges to get around access issues with multiple sites amanaged on the same SmartCenter.
6. Better control for users on which sites they need to access.

And that's just off the top of my head. I've been working a lot in this space lately, and it's sad to say that CP have lost their lead on Remote Access VPNs. Proviiding that granularity would help a lot to get them back on track.

[melipla]

1. They could improve this without adding a second remote access community, as the remote access community itself doesn't have any topology configuration. With the addition of RA VPN Domains I think they realize this as well. They would probably just make this group based.
2. Regardless of secureclients, site to site tunnels would have problems with overlapping encryption domains--adding a second RA community wouldn't address this. You can OM the secureclients so you can't count them as overlapping with your internal IPs.
3. I'll concede that CP's implementation is limited here. They'd be forced to address this issue if they were to add in additional remote access communities, but you could easily fix this without adding a second remote access community. I think CP realized everyone's using two-factor authentication w/radius which you can use to control what users are allowed to connect to each gateway so CP has not improved this.
4. Use ipassignment.conf. Although a GUI for this would be beneficial.
5. I don't think OM is a kludge, its a valid way for me to source IP authenticated users & not worry about IP conflicts--which will always be a concern even with multi-RA communities. Hub mode / non Hub mode / MEP offer good flexibility in configuring how you want your community to operate.
6. Well you have traditional mode if you want that granular control. For simplified mode there's Finance@Gateway_A_OM configurable rules which you can use to restrict down to a user level and give granular service access to. No need for a new RA community there.

I'm just throwing out some ideas....I can do everything you listed with one Remote Access community. However that doesn't mean I wouldn't like to see improvements / new features as well.

[Thorpuse]

1. The encryption domain is gateway-based, not community based. The biggest issue here is partial topology overlap, which causes everyone's site updates to fail. This is messy....
2. See 1. See also the fact that OM is assigned by the first gateway you connect to, which makes IP Assignment or any other method or reliably enforcing interior controls difficult.
3. All_Users@Any Rules.
4. See 2.
5. See 1. No support for partial (proper subset) topologies is a killer. MEP requires every gateway to have the same RAS encryption domain. This means performance penalties if the internal sites are connected by slow or congested internal links. MEP also doesn't allow you preference which site you should connect to for which destination. In short, MEP and Hub-mode etc are not useful for geographically dispersed RA Communities.
6. See 2.

All of the above can be managed by a single RA Community, but it starts getting a lot more complicated, especially when you have to explain to users about advanced configuration settings and modifying profiles/profile settings. Technically, there's little that is challenging about Multiple RA Communities. Multiple OM addresses on SecureClient may be a little more complicated, but still viable.