Captive Portal doesn't work for remote offices

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Captive Portal doesn't work for remote offices

L1 Bithead

Greetings to all

I have the scenario described in the graph:

adiazm_0-1630073510049.png

 

I use Captive Portal based authentication for certain devices. It works fine for the LAN zone, but not for the WAN zone.

In the WAN Zone we have remote offices that connect through the MPLS of a service provider. Then, over that data link, we build an IPSec tunnel to establish the connection between the main office and the branch office.

Time Out occurs when a device tries to access the Internet from the WAN.

The captive portal is assigned to Interface ethernet1 / 1 with IP address 192.168.1.1

Any idea what is the reason why the captive portal to the WAN is not working?


Best regards.

Antonio Díaz Meneses
1 accepted solution

Accepted Solutions

Hello!

tunnel.2 does not have IP address.

I solved the issue.


Between the Firewall and the carrier link I placed an IPsec router.


I let the tunneling work to the new device and assing an IP and a management profile to the interface ethernet1/2.


It seems that the authentication web interface cannot be read from incoming connections in a different interface.


I will share the new diagram.

adiazm_0-1638807791074.png

 


Regards.

Antonio Díaz Meneses

View solution in original post

4 REPLIES 4

L3 Networker

If this is configured as auth policy with captive portal in redirect mode to 192.168.1.1:

1) Did the URL bar actually change (redirect) to 192.168.1.1:6080-6083 ?

2) Check the traffic log for this, you may have a policy-deny from WAN to LAN 192.168.1.1

3) Does the device 192.168.2.1 definitely have a route for 192.168.1.1 to the FW? Does the FW have a route back the right way?

 

- DM

Sr. Technical Support Engineer, Strata

Hello!

Thanks for your answer... I am very sorry for my delay answering....

technically, the three points you indicate are fulfilled.

I'll give you a detail of the session where the client tries to open the portal:

 

adiaz@PA-220> show session id 39672

Session 39672

c2s flow:
source: 192.168.2.133 [AGENCIAS]
dst: 192.168.1.1
proto: 6
sport: 53521 dport: 6082
state: INIT type: FLOW
src user: unknown
dst user: unknown

s2c flow:
source: 192.168.1.1 [LAN]
dst: 192.168.2.133
proto: 6
sport: 6082 dport: 53521
state: INIT type: FLOW
src user: unknown
dst user: unknown
qos node: tunnel.2, qos member N/A Qid 0

start time : Wed Sep 22 11:47:32 2021
timeout : 90 sec
total byte count(c2s) : 330
total byte count(s2c) : 0
layer7 packet count(c2s) : 5
layer7 packet count(s2c) : 0
vsys : vsys1
application : incomplete
rule : AGENCIAS - MATRIZ
service timeout override(index) : False
session to be logged at end : True
session in session ager : False
session updated by HA peer : False
layer7 processing : enabled
URL filtering enabled : True
URL category : any
session via syn-cookies : False
session terminated on host : True
session traverses tunnel : True
session terminate tunnel : False
captive portal session : False
ingress interface : tunnel.2
egress interface : ethernet1/1
session QoS rule : N/A (class 4)
tracker stage firewall : host service
end-reason : aged-out

 

This is the client:

adiazm_0-1632330172377.png

auth.agroproduzca.com.ec points to the IP address 192.168.1.1

 

Again, thanks for your apreciated help.

 

REgards!

Antonio Díaz Meneses

Cyber Elite
Cyber Elite

Thank you for providing additional information @adiazm

 

Have you configured: management profile on interface: tunnel.2 and enabled: Response Page?

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClKZCA0

 

Kind Regards

Pavel

Help the community: Like helpful comments and mark solutions.

Hello!

tunnel.2 does not have IP address.

I solved the issue.


Between the Firewall and the carrier link I placed an IPsec router.


I let the tunneling work to the new device and assing an IP and a management profile to the interface ethernet1/2.


It seems that the authentication web interface cannot be read from incoming connections in a different interface.


I will share the new diagram.

adiazm_0-1638807791074.png

 


Regards.

Antonio Díaz Meneses
  • 1 accepted solution
  • 2825 Views
  • 4 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!