Question |
|
What is the use of firewall allow-tri-session and how is it is useful in implementing Captive portal authentication in a Layer 2 Deployment. |
Environment |
|
In most scenarios we expect a Layer3 VLAN for Captive portal authentication to work for clients as we expect controller to have Layer3 reachability to the clients. In this article, it describes about how to get Captive Portal working on L2 Deployment |
Captive portal is a layer3 authentication method. In order to make it work in a layer 2 deployment environment, we need to make sure the controller have layer3 reachability to the client. This can be achieved by 2 ways:
1 configure an IP address on the client vlan(this is not a layer2 deployment in some sort. 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 send 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.
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 do the dns lookup and resolve the IP.
2 the client send out the SYN packet to the resolved IP. The packet reach 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 the client vlan y and controller vlan z. so the router will do route lookup, find the client is on it’s local vlan y, then it will ARP. The ARP reach the controller, controller send it to the client (since it’s a bcast). Client reply, controller send 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(not sure how to explain this here. Could because the controller will only allow session to be initiated by the user not from the internet so it will drop it), 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
The difference is once the controller receives the packet from the router, it will encapsulate the packet in GRE and send 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