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...
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.
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.
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/WiFi/17 (192.168.30.32)
vsys1 192.168.30.1/WiFi (192.168.30.1)
11517 web-browsing ACTIVE FLOW NS 192.168.30.32/WiFi/6 (22.214.171.124)
vsys1 126.96.36.199/untrust (188.8.131.52)
40928 ssl ACTIVE FLOW ND 192.168.30.32/WiFi/6 (192.168.30.32)
vsys1 192.168.110.1/captive-portal (127.3.1.1)
but here isn't dhcp traffic :smileysad:. 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).
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.
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.
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 :smileysad:.
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?
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!