Fun with IA Portal Sharing and Spoofing….But not too much fun

There is this cool feature you can use to:

  1. Centralize your portals
  2. Limit the number of portals you have to configure and support
  3. Users only have to remember 1 portal instead of 100
  4. Centralize the portal, but if it breaks you can still authenticate at the local portal

So it looks something like this:

  • User authenticates at central Captive Portal
  • User can then have access to ANY of the sites whose firewalls share that user database on fw-1:

Slide1

 

How is this all done?? Well, you first have to allow the fw-1 system to share identities with the remote sites:

Slide2

And on the remote sites you have to point to the fw-1: corporate identity awareness portal:

Slide3

Waaaalaaaa done. Works. Ship it. Finished. Chapter Over. Go watch TV and a beer and pizza and chill. OK, seems simple doesn’t it?  Hahahahahaha. Pretty funny.

Let’s look what happened underneath the covers.

Slide4

PEP and PDP setup connections with each other.

 

Slide5

 

 

PEP and PDP setup connections with each other. PEP needs to share the user table that PDP is holding on the fw-1: Corporate IA Portal

These are the ports that are being used to do that. You can see there are the main ports and then some random ports it spawns off.

Slide6

Slide7

 

 

 

So now comes the fun part. Not sure how your network setup is, but I saw connections come from all interfaces to all interfaces. I didn’t debug but I think it depends on which interface Captive Portal is running. Anyways the result was a ton of spoofing drops. Took me a while to figure out what was going on.

In addition, if you have firewalls between the fw-1 and the remotes, they you have to open these ports so they can talk IA.

Slide8

So to fix this whole mess, I had to put the firewalls into spoof groups on all interfaces. I also set the spoof to DETECT for a bit until I knew it all worked and then turned it back to PREVENT.

Slide9

Install policy on both fw1 Corporate IA Portal and fw2 remote.

After I did this CP actually has been working awesome so far. Remember this is with multiple AUs in a single AD domain and a single MDS domain – which is what CP strongly warns you against.

 

 

 

Advertisements
Post a comment or leave a trackback: Trackback URL.

Comments

  • .Q  On March 5, 2015 at 2:41 pm

    But it gets really ugly if you start to cross domains…
    https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk65404

  • Dreezman  On March 5, 2015 at 2:43 pm

    oh yeah. if you cross AD domains that is

  • Dreezman  On March 5, 2015 at 2:51 pm

    oh wow…and MDS domains. wow that is ugly.

  • Tobias Moritz  On April 9, 2015 at 9:57 am

    In some environments, these strange pdppep connections over unexpected interfaces are really a problem because you don’t want to have this traffic crossing unsecure networks.
    We did some investigations with R77 GA on our side and it seems to always use the IP address set as main address in gateways cluster object (in CP database) as destination (source IP is chosen based outgoing interface, which is chosen based on routing decision). When your firewalls are facing Internet and your main IP address is the external one (needed for some features with IPSec blade), your pdppep traffic is flowing through internet. I guess you don’t like that.
    We tried a workaround using a NAT rule redirecting traffic with destination main-IP:28581 and main-IP:15105 to an interface address we want, but… It didn’t work. Log shows traffic matches this NAT rule, but translation of destination address did not occure. table.def on management station shows no NAT exception for these ports, but there has to be some extra magic.
    It would be nice if this trick would work, because PDP deamon listens on 0.0.0.0.
    So the only way to fix this was to manipulate routing table to get the traffic flowing through the interface we want. Of course, we had to modify antispoofing for this interface to allow the return packet. However, this way we made sure, pdppep traffic is only flowing the way we want.
    Please keep in mind: This routing trick may get you into trouble if you need traffic between the main IP of both gateways which is not PDPPEP traffic.
    I hope Checkpoint will fix this soon in providing a way to specify exact addresses for Identity Sharing.

    • Dreezman  On April 9, 2015 at 12:54 pm

      Really valuable info! I was intending to dig into this and haven’t gotten there yet.. THANKS!

  • Tobias Moritz  On April 10, 2015 at 1:03 am

    Update: We tested with R77.20 GA, not R77 GA. So I cannot say if this works this way when using older versions.

  • Tobias Moritz  On April 10, 2015 at 4:52 am

    Update2: A view minutes ago, I got a confirmation from CP support for this behavior: “The sharing gateway is communicating with the IP address that is configured on the gateway object.”. I also got another workaround from them:

    1. Login to SmartDashboard.
    2. Create a “dummy” firewall object with the internal (actual) IP address of the shared gateway.
    3. On the “dummy” firewall object, enable Identity Awareness and Identity Sharing.
    4. On the “dummy” firewall object, under Identity Sharing, in the “get identities from other gateways” area, select the gateway that is supposed to share identities with the internal IP address.
    5. Do not select the “share local identities” for the dummy object.
    6. Push Policy.

    This workaround sounds like a very dirty hack but it may help you, if my workaround with modified routing is not applicable in your environment.

    I will drop a note if we were able to verify this workaround, but this will take a while.
    @Dreezman: Maybe you can test this in your lab?

  • Dreezman  On April 10, 2015 at 6:01 am

    Will do if I get time. Busy on some other things.

  • Dreezman  On April 10, 2015 at 6:01 am

    great! update!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

blog.lachmann.org

Michael Endrizzi's - St. Paul MN - CheckPoint blog on topics related to Check Point products and security in general.

%d bloggers like this: