- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
08-27-2021 07:16 AM
Greetings to all
I have the scenario described in the graph:
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.
12-06-2021 08:21 AM
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.
Regards.
08-27-2021 09:19 AM
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
09-22-2021 10:03 AM
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:
auth.agroproduzca.com.ec points to the IP address 192.168.1.1
Again, thanks for your apreciated help.
REgards!
09-26-2021 12:59 AM
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
12-06-2021 08:21 AM
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.
Regards.
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!