About mgarg

mgarg · ‎11-24-2017

It seems when you have the decryption rule enabled, firewall is failing to decrypt the session and ending with cert validation error. Open up a case with TAC to check why the decryption is failing. There was a bug reported on 7.1.4 code for 3k devices where the decryption failed to proxy memory pool exhaustion and was fixed on 7.1.11 or 8.0.3 But getting a validation from TAC engineer would be the first step here.

mgarg · ‎11-23-2017

If you have any previously installed vpn client, like cisco any connect, try uninstalling that first. Then re install the global potect.

mgarg · ‎11-23-2017

In the logs i see this error "failed authentication for user 'angusg'. Reason: User is not in allowlist" In your authentication profile change the user domain to none ( you will have to type it) and keep the user name modifier as %USERINPUT%

mgarg · ‎11-20-2017

I see an authentication success message in the logs 'Authentication succeeded for user "test"2.' Can you try connecting from Global protect client with the same user and share the output from the authd.log. You can run a "tail follow yes mp-log authd.log" in the command line when attempting to connect from client.

mgarg · ‎10-31-2017

I think you are talking about the commit logs. Go to Monitor > Logs > Configuration. Here you can check what changes were made when and by who.

mgarg · ‎10-30-2017

For BYOD, you can use captive portal to learn the mapping. https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-Captive-Portal/tac-p/60461#M926

mgarg · ‎10-27-2017

Should not be an issue if everything is setup fine else open up a ticket with TAC for faster resolution.

mgarg · ‎10-27-2017

as per the diagram, your network setup is quite simple. You just need to have the servers and the firewall's internal interface on the same subnet and configure the firewall as the default gateway for the servers. On the outside interface configure the public IP your isp have provided. Create a security/nat policy from inside to outside for outbound. Similarly, for inbound traffic, you will have to setup port forwarding/DNAT rules and security rule to allow traffic to hit the servers. https://www.paloaltonetworks.com/documentation/80/pan-os/pan-os/networking/nat/nat-configuration-examples/destination-nat-with-port-translation-example#id053beeb9-fde0-445b-99d0-5dd5a1000b7c

mgarg · ‎10-27-2017

in the global counters i see a warning "tcp_drop_out_of_wnd - out-of-window packets dropped". As per the packet captures the client seems to be resetting the connection because the 3-way handshake is not completing and the weird part is that it sends retransmission packets after sending rst packets. Anyway, here is an explanation as to why the firewall is dropping the packet and you can test if the command that is given below to check if it works ( Just a way to confirm the problem and not a solution). tcp_drop_out_of_wnd - out-of-window packets dropped The Palo Alto Networks Firewall creates a sliding sequence window starting with the original ACK (the window size is based on the type of traffic within the session). It is expected that the packet sequence numbers within the current session reside within this sliding window. This window adjusts with the type of traffic and whenever new ACK messages are received. The default behavior on the device is to drop packets when sequence numbers are outside this window. This feature can be added to the config file and applied with a commit, which is required to override the default behavior after rebooting: > configure # set deviceconfig setting tcp asymmetric-path < bypass|drop > # commit I think the packets that you have captured are client side. It would be more helpful if you can capture the packet on the firewall as well for receive, transmit and drop stage. That way you can check what response is received from the server before the firewall drops the packet.

mgarg · ‎10-27-2017

This does not seem to be an SSL issue because we do not see even the 3-way handshake completing. For the first packet from source port 57901, there is not corresponding syn ack. What is see is an 'Ack' packet from the server, which is something the client would not be expecting and thus resets the connection in the following packet. Take simultaneously pcap on firewall and client and compare packets for one particular stream. Also, you can check global counters. On the firewall set the filter as source 10.160.74.142 and destination as 193.41.234.29. Turn on the filter, access the website and in the cli type "show counter global filter packet-filter yes delta yes" 3 -4 times. If the firewall is sending rst due to some reason, then counters should show some reason. Post your results.

mgarg · ‎10-26-2017

You will have to setup xauth configuration in the global protect to use the Linux based VPN client to connect to the gateway. Starting with PAN OS 5.0, xAuth is supported with VPNC on a couple of distros. The following VPN clients are now supported for GlobalProtect VPN access: o Ubuntu Linux 10.04 LTS VPNC o CentOS 6 VPNC

mgarg · ‎10-26-2017

natively global protect agent is not supported for linux systems. You can use the native VPN application. However, you can try running the global protect application with WINE and it would be interesting if this works https://www.pcworld.com/article/2900497/how-to-run-windows-software-in-linux-everything-you-need-to-know.html Post any results that you come across.

mgarg · ‎10-26-2017

I am assuming that currently, you have a router which takes of your incoming and outgoing traffic for the servers. If this is true then make firewall as the default gateway for the servers and then connect the firewall to router over a different interface. Setup nat and security policies accordingly. If you can share your current network diagram, then I should be able to suggest further.

mgarg · ‎10-26-2017

Some from the engineering team should be able to comment on whether all virtual interfaces get same mac address as per design. As far as configuration is concerned, I don't believe there is a setting which allows you to force unique mac addresses or assign them statically.

mgarg · ‎10-26-2017

There is a possibility that the application might be pulling info from a different URL that could be blocked due to URL filtering profile. To find that URL, create an URL filtering profile and keep all categories as "Alert". Create a test rule for one test machine and apply this URL filtering profile. Access the application from this test machine. Now when you head over to the URL filtering logs, you can see what all URL links were accessed. Identify the ones that could be related to the application and whitelist them in your original rule. Then disable the test rule and check if the application works.

mgarg · ‎10-26-2017

Go to Monitor > System Logs. Filter with (subtype eq globalprotect). This will filter all global protect logs. These logs will show you when users connected and disconnected from the gateways. There are a bunch of other logs that you will see but you can always modify the filter to show you specific logs.

mgarg · ‎10-24-2017

For this requirement, you will have to setup internal gateway along with internal host detection. Once the user is inside the network, GP will automatically detect that with the help of internal host detection and connect to the internal gateway. On the internal gateway, you do need to configure tunnel mode, so the GP users will still keep the original private ip. Since they will be authenticating to the gateway, a user-ip mapping will be created for them with type GP. this doc is a little old but should get you started https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-Internal-GlobalProtect-Only/ta-p/54099 Note: Internal host detection does not work if the connect method is "on -demand". It has to be User-logon

mgarg · ‎10-23-2017

For testing create an any any policy to check if that resolves the issue. If that helps, then create a bidirectional security policy from between your inside and outside zone and allow the dhcp application.

mgarg · ‎10-20-2017

Go to Device > server profiles > syslog. Once the profile is created, head over to the objects > Log forwarding. Here you will need to create a profile and mention syslog server profile that you created initially. Once the log forwarding profile is created, you need to apply this to security policies under the Action tab, for the firewall to actually forward logs to your syslog server.

mgarg · ‎10-17-2017

the reason there is no session on the firewall because i think it dropping the packet due to security rule . You can confirm this by creating a deny alll rule at the bottom and see if your traffic hits this rule. The service object rdp that you have created, make sure you just put 3389 in destination port and leave the source port as blank and the protocol is tcp. If this still does not work, open the rule to allow any service. For security just mention your public ip as source. Check if you are still hitting the same rule or the default deny.

mgarg · ‎10-15-2017

at this point. take a pcap on firewall and client together. Share the details. Provide the below details After trying rdp connection ,in the command line type 1) show session all filter source<your_public_src_ip> destination 113.160.131.230 destination-port 3389 this command will list the running sessions and the left most column is session id. Select a session id 2) show session id<session_id>

mgarg · ‎10-15-2017

the reason why you are not able to get to internet, once you disable the nat policy , is because your modem does not know how to reach 192.168.250.0/24 network for the return packet and hence it would drop it. Add route on your modem to route traffic for 192.168.250.0/24 to 192.168.150.10

mgarg · ‎10-15-2017

take a packet capture on the firewall and the end client. If you see the syn packet on the end client this would mean the packet is getting forwarded to the client. Check if you recieve a syn-ack back on the firewall from the client. If that is not the case then , check the routing on the switch. For testing in the nat rule that you have created for inbound, source nat the traffic to the trustzone interface. Share the output of pcaps and session if this still does not resolve

mgarg · ‎10-02-2017

look at the system logs and filter with (subtype eq vpn) .If you seel messages saying failing due to negotiation timeout then take a packet capture on palo alto and checkpoint to check if you are sending/receiving isakmp packets Run a test vpn ike-sa gateway <gateway> and have a look at mp-log ikemgr.log for more info

mgarg · ‎09-06-2017

This seems to be more of a client issue than anything related to firewall. From the logs that you posted earlier, it looks like the Pan agent is not able to start the pan gp service. Could you please confirm if the PANGPS service is running under Task manager > Services. Try uninstalling the software and get rid of the Palo Alto Networks folder in Program Files. Re install and check if this resolves. Open up a tac case if this does not work.

mgarg · ‎09-06-2017

Do you see PanGPS service running under the task manager for these users?

mgarg · ‎07-13-2017

Try taking a simultaneous pcap on the ubuntu box and the firewall and compare them if the client generates a rst packet Move over you can take the global counters during the test In the command line run show counter global filter packet-filter yes delta Just make sure your filters are setup to include only the source machine from where you are testing. If you can please share the output of counters

Date Registered	‎10-28-2016 06:42 AM
Date Last Visited	‎10-05-2018 10:35 AM
Total Messages Posted	79
Total Likes Received	7

Online Status	Offline
Date Last Visited	‎10-05-2018 10:35 AM

Strata

Prisma

Cortex

About mgarg