topic Re: Captive Portal - need help with configuration in General Topics

Captive Portal - need help with configuration

_slv_ — Thu, 12 Dec 2013 16:51:57 GMT

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)

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

and one CP policy:

My NAT policy looks like:

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

Re: Captive Portal - need help with configuration

tasonibare — Fri, 13 Dec 2013 00:31:44 GMT

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

Re: Captive Portal - need help with configuration

_slv_ — Fri, 13 Dec 2013 09:38:43 GMT

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

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:

"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 . 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

Re: Captive Portal - need help with configuration

tasonibare — Mon, 16 Dec 2013 20:41:09 GMT

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

Re: Captive Portal - need help with configuration

tasonibare — Mon, 16 Dec 2013 20:48:46 GMT

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

Re: Captive Portal - need help with configuration

_slv_ — Tue, 17 Dec 2013 20:50:40 GMT

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 .

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