Security

I am trying to deploy ClearPass and the way our network is designed requires us to use the tri-session with DNAT option.  I am running into a problem where some of the traffic has to traverse a Fortinet IPS and is being blocked.  We use virtual networks on our campus and in our case, the ClearPass server and the Controller's IP are in one virtual network and the wireless users off the controller are in a different virtual network and there is a Fortinet IPS in between.  In our test scenario, I can move the users into the same network as the ClearPass server and the controller and everything works; unfortunately, I am unable to do that across the board.

 

I would really like to have a detailed understanding of the traffic flow that includes when destinations are NATed, how the controller sends traffic (does it always go through the network routing, or does it send directly to the user since they are in the user table).  As much detail as possible is appreciated.

 

Thanks

 

Amel

Here is the description of the feature in the user guide - "

Allows three-way session when performing destination NAT. This option should be enabled when the controller is not the default gateway for wireless clients and the default gateway is behind the controller. This option is typically used for captive portal configuration"

 

However, the question is why is the IPS blocking it?  Do you have any details on the logs from Fortinet?  

We ran a trace on the fortinet and were seeing "no session matched". A corresponding packet trace on the client shows it sending SYN packets and no response coming back to it. This is why I want to understand in detail how this works. I need to know when DNAT is taking place and how the controller forwards packets.

I suspect one of two scenarios:

The client traffic traverses the network (through our Fortinet) and the controller bypasses the network and sends directly to the user from the user-table entry.

Or adversely, the controller intercepts the user traffic from the user so it can intercept and sends traffic back to the user through the network.

Both result in the Fortinet only seeing one direction of the conversation which it drops.

Thinking about it the latter scenario actually makes sense. Either way, I need to understand how this works so we can design around it.

Let me try to explain this further:

 

Configuring a Captive portal in a layer2 deployment

 

Captive portal is a layer3 authenticaton method. In order to make it work in a layer 2 deployment environment, we need to make sure the controller has layer3 reachability to the client. This can be archieved in 2 ways:

 

1. Configure an IP address on the client vlan(this is not a layer2 deployment. However, since this IP is not the client default gateway, the packet is still pass through the controller. It still layer2 from datapath perspective) When the controller sends out the syn-ack, it knows that the client is reachable locally and will do ARP and sent out the packet.

 

2.  Enable ‘firewall allow-tri-session’ command. Please check the example below:

 

Topology:

 

 

 

The client is on vlan y. The controller doesn’t have an IP address for vlan y interface. The controller has an IP address on vlan z and it’s the vlan that will do routing between controller and router.

 

Without the ‘firewall allow-tri-session’ command:

 

1. Client does a DNS lookup and resolves the IP.

2. The client send out the SYN packet to the resolved IP. The packet reaches the controller through GRE tunnel. The controller will reply with ‘SYN-ACK’ on behalf of the real destination. Since the controller doesn’t have an IP on the client vlan, the controller will do route lookup and send out the packet to the router on vlan z.

3. On the router, it has both the client vlan y and controller vlan z, so the router will do a route lookup, find the client is on it’s local vlan y, then it will ARP. The ARP reaches the controller, the controller sends it to the client (since it’s a bcast). Then, the client replies and the controller sends it back to the router. The router will know in order to reach the client, the packet should be sent to the controller but on vlan y.

4. The controller receives the packet. Since the controller doesn’t allow the tri-session (because the controller will only allow session to be initiated by the user not from the internet), it will drop the packet.

 

Here’s the example of the ‘show datapath session table ‘ output:

10.168.121.207 is the client IP address. 4.2.2.2 is the dns server IP. 10.168.15.20 is the switchip

 

(c1-10) #show datapath session table 10.168.121.207

 

Datapath Session Table Entries

------------------------------

 

Flags: F - fast age, S - src NAT, N - dest NAT

       D - deny, R - redirect, Y - no syn

       H - high prio, P - set prio, T - set ToS

       C - client, M - mirror, V - VOIP

 

  Source IP     Destination IP  Prot SPort DPort  Cntr Prio ToS Age Destination Flags

--------------  --------------  ---- ----- -----  ---- ---- --- --- ----------- -----

10.168.121.207  4.2.2.2         17   1096  53     0    0    0   1   tunnel 9    FC

66.199.187.182  10.168.121.207  6    80    2168   0    0    0   0   3/0         FDC

4.2.2.2         10.168.121.207  17   53    1096   0    0    0   1   tunnel 9    F

10.168.15.20    10.168.121.207  6    8080  2168   0    0    0   1   tunnel 9    S

10.168.121.207  66.199.187.182  6    2168  80     0    0    0   0   tunnel 9    NYC

  

With the ‘firewall allow-tri-session’ command enabled 

 

The difference is once the controller receives the packet from the router, it will allow the packet to be sent to the client.

 

Here’s the show datapath session table’ output:

 

(c1-10) (config) #show datapath session table 10.168.121.207

 

Datapath Session Table Entries

------------------------------

 

Flags: F - fast age, S - src NAT, N - dest NAT

       D - deny, R - redirect, Y - no syn

       H - high prio, P - set prio, T - set ToS

       C - client, M - mirror, V - VOIP

 

  Source IP     Destination IP  Prot SPort DPort  Cntr Prio ToS Age Destination Flags

--------------  --------------  ---- ----- -----  ---- ---- --- --- ----------- -----

207.17.137.229  10.168.121.207  6    80    2177   0    0    0   1   local       F

10.168.121.207  10.168.15.20    6    2177  8080   0    0    0   1   local       FY

10.168.121.207  10.168.15.20    6    2178  443    0    0    0   1   tunnel 9    FNC

10.168.121.207  4.2.2.2         17   1096  53     0    0    0   1   tunnel 9    FC

4.2.2.2         10.168.121.207  17   53    1096   0    0    0   1   tunnel 9    F

10.168.15.20    10.168.121.207  6    443   2178   0    0    0   1   tunnel 9    FS

10.168.15.20    10.168.121.207  6    8080  2171   0    0    0   0   local       FDYC

10.168.15.20    10.168.121.207  6    8080  2177   0    0    0   1   tunnel 9    FS

10.168.121.207  207.17.137.229  6    2177  80     0    0    0   1   tunnel 9    FNC

 

 

 

Thanks Seth.  This is very helpful and seems to confirm that the controller, when sending to a user on a VLAN that it does not have an IP on, send back to the netwrok from its management VLAN and lets the network route back to the user.

 

The other questions I have related to this are during the ClearPass authentication process, when is the controller performing NAT functions.  For each step, can you tell me if the controller is NATing or not?

 

The basic process I see is:

 

Pre auth URL redirection    --- this is NATed

CPPM preauth page --   

Shibboleth athentication -- 

CPPM postauth  ---

Post auth URL redirection -- This is again NATed

User accessing network -- This is not NATed

 

The other question I need to understand is; if we were to set up a VLAN dedicated to the CP-REDIRECTION would its traffic still egress from the controller on the management VLAN or would we be able to somehow direct traffic through its VLAN.

 

 

So...here's the thing.  The controller can NAT or not NAT based on how the network and role policy is setup.  I would need to see your config to tell you more but essentially, the guest network can be routable on the internal network and therefore "see" the clearpass guest server without any NAT needed.  

 

Otherwise, you can enable source NAT in the pre-auth guest role OR the IP interface on the controller.