Captive Portal - need help with configuration

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Captive Portal - need help with configuration

L4 Transporter

Hello

I'm using CP since over 6 months. It's working quite good.

I moved my servers from internet (untrust zone) to my DMZ zone. I realized that traffic between WiFi network and servers in DMZ (using public adreses) is allowed without CP.

In WiFi zone I have two networks: WiFi and WiFi_konferencja - traffic between them also should be blocked.

I created two security policies (that are now disabled)

2013-12-12_172736.png

2013-12-12_172934.png

Policies in red rectangle are used without CP for four AP's with old config. This isn't a problem.

and one CP policy:

2013-12-12_173053.png

My NAT policy looks like:

2013-12-12_173651.png

How to fix my policies to make evert traffic from WiFi zone and WiFi network must be redirected to CP first, and afer authentication allowed?

Why security policy "'WiFi blokowanie koniec2" blocking a lot of traffic from IP's from that zone to gateway to port 67? I have dhcp server on gateway interface in WiFi network.

Comnputers in WiFi network got proper IPs...

For clarification:

DMZ has network 10.100.10.x

WiFi has 192.168.30.x

www_zew has public IP

www_wew has private 10.100.10.100

Help me please. In doc according CP there isn't such situation explained.

Regards

SLawek

5 REPLIES 5

L3 Networker

SLawek,

Your requirements are a little unclear, but I think you are trying to describe two issues, so please correct me if I'm wrong.

Q1. You need every traffic from WiFi zone going to the DMZ_wew zone to get captive portaled. Correct?

A1. Your captive portal policy is configured to only CP traffic going to Moodle_zew and WWW_zew destinations. If your users traffic are going to other destinations not included in these 2, then they will not get CP'd. Can you change the destination network to 'any' and see if they start getting captive portaled?

Q2. You are seeing "WiFi blokowanie koniec2" security policy block DHCP traffic that is supposed to be in the same zone. Correct?

A2. Based on the security policy configured, if there's no other matching rule for DHCP traffic until it hits this rule, then even the same zone traffic will be denied because of the 'any' destination zone.

Let me know if my understanding of the problems are clear.

Regards,

tasonibare

Hi Tasonibare

Sorry for my english ...

Q1: Yes, my captive portal policy is configured to only CP traffic going to Moodle_zew and WWW_zew destinations. I did it for testing purposes.

Today I changed it to any

2013-12-13_101538.png

and I got strange for me situation.

From VM Linux workstation (the same I used earlier) from WiFi network I CAN open webpage of Moogle (using it public address) by HTTPS without redirecting to CP, when I put in browser HTTP adress I get CP login page.

Q2: Correct, I know it - but I;d like to someone confirm it for me too.

My policies looks like:

2013-12-13_102045.png

"WiFi 1" and "WiFi 2" should block traffic between this two networks, and it did.

I don't understand what is going with same zone traffic.

Before I add policy "WiFi to WiFi" my VM get dhcp responce from server.  I try to "catch" traffic from CLI.

I disconnected VM and connected again and immediately I launched from CLI:

admin@PA-200> show session all filter source 192.168.30.32

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

ID      Application    State   Type Flag  Src[Sport]/Zone/Proto (translated IP[Port])

Vsys                                      Dst[Dport]/Zone (translated IP[Port])

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

9315    dns            ACTIVE  FLOW       192.168.30.32[49409]/WiFi/17  (192.168.30.32[49409])

vsys1                                     192.168.30.1[53]/WiFi  (192.168.30.1[53])

11517   web-browsing   ACTIVE  FLOW  NS   192.168.30.32[36821]/WiFi/6  (94.124.14.143[13414])

vsys1                                     94.124.11.170[80]/untrust  (94.124.11.170[80])

40928   ssl            ACTIVE  FLOW  ND   192.168.30.32[40159]/WiFi/6  (192.168.30.32[40159])

vsys1                                     192.168.110.1[6082]/captive-portal  (127.3.1.1[6185])

but here isn't dhcp traffic Smiley Sad. In system log is a entry "'DHCP lease started ip 192.168.30.32 --> mac 00:50:56:aa:62:85, interface ethernet1/4.3'"

but this traffic doesn't hit  "WiFi to WiFi" policy (I have log at session end enabled).

With Regards

Slawek

Thanks for the clarification and sorry for the delayed response.

1. From your CP policy, you have the service set to 'default'. This would only hijack HTTP traffic and not HTTPS traffic. (Sorry I missed this in my first response).

You need to enable both http and https services in the CP policy in order for the firewall to hijack both types of traffic.

Furthermore, even though the firewall was not hijacking HTTPS traffic for CP, the only reason why the traffic was successful is because there's a security policy permitting SSL for 'any' or 'unknown' users.

Verify that you are only permitting SSL access for known users from the Wifi zone to the internet zone.

2. If the PA interface is configured to be your DHCP server, then we do not log the DHCP negotiation in our traffic logs. These are host services and not traffic traversing the firewall's DP and that's why it doesn't get logged, or a session created for you to see in CLI.

Regards,

tasonibare

Just to add, if you need to see DHCP negotiations, allocations and events, you can tail or less the dhcpd for this information.

> tail follow yes mp-log dhcpd.log

(for more information, you can also set the dhcpd to debug mode with the 'debug dhcpd global on debug' debug).

P.S.: Always remember to turn off debugging when done troubleshooting so the device doesn't crash on you.

Regards,

tasonibre

Hi Tasonibre

AD1. I changed my both CP policies (from WiFi to untrust and WiFi to DMZ_wew) from "default" to http and https

When  I try to open http webpage (doesn't matter it's from DMZ or Untrust) it's working prefectly and webbrowser i redirected to CP.

When I try to open https://paloaltonetworks.com I get "The connection was reset  The connection to the server was reset while the page was loading." - that's OK - I didn't authorise my session. I have problem when I try to open https://mywebpage.com (served from DMZ_wew) - the webpage is loading without any problems Smiley Sad.

Where is my problem? I'd like to stop https traffic to DMZ_wew zone in the same way as to Untrust.

I need clarification according to same zone traffic. Should I add security policy allowinf same zone traffic or it's not nesssary?

Regards

Slawek

  • 3663 Views
  • 5 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!