About aleksandar.astardzhiev

I have recently receive similar error, trying to establish LDAP connection.   Interestingly the issues had nothing to do with this attribute. I already forgot what was actually the issue - I believe it was something with wrong bindDN (or pass).   So I would definately support the previous comment and encurage you to make a packet capture with filter your AD server as source and  destination. Plaintext LDAP is straight forward - you you wiill see bindRequest from the firewall, sending the username and the password, if successfull you should see success as reply. ... View more

Hi @relayer,   Upgrading the PanOS is independant to the GlobalProtect client. You control the GP version through Device -> GlobalProtect Client. The OS upgrade is not upgrading the GP automatically. More important - depending on your GP portal config you can connect with higher or lower version than the current active one, which gives you few availble options:   - Upgrade the PanOS to 7.1; - leave the current GP active version as it is; - confirm that your GP portal is not forcing user to update the client (network -> gp portal -> agent -> app -> allow user to upgrade gp app -> select allow manual or disable); - download newer version and test it; - once happy with result, change the app settings to upgrade all users   ... View more

Fist I would suggest you to disable the bi-directional for the source NAT and configure manually destination NAT. The main reason for that is - What does the Bi-directional NAT Feature Provide? My phisosofy is to enable bi-directional only for static NAT going to public. NATing for VPN could be little bit tricky. So I would suggest the following:   ## Source NAT IPSecVPN_xxx-1 { to [ IPSec_xxx ]; from [ LAN_Servers ]; source [ 192.168.2.0/24 ]; destination [ 10.95.0.0/16 ]; source-translation { static-ip { bi-directional no; translated-address 10.0.2.0/24; } } } #### Destination NAT IPSecVPN_xxx-2 { to [ Untrust ] from [ IPSec_xxx] source [ 10.95.0.0/16 ] destination [ 10.0.2.0/24 ] destination-translation { translated-address 192.168.2.0/24; }  Note: that the to zone in your destination NAT should  be zone based on your routing table for 10.0.2.0/24. If you don't have route for such network, traffic will be routed with default route to outside (or your what ever default is related). if you have route matching this network (for example 10.0.0.0/8) you need to put the zone following this route)   Remember: • NAT rule must be configured with pre-NAT zones (zones matching the addresses before the NAT) • Security rule must be configured with pre-NAT addresses, but post-NAT zones   Having the bidirectional enabled should work indeed, so if the traffic is failing I would suggest: - Check the rule on the Fortigate at the other end - Check the routing on the Fortigate at the other end - Check if encrypted packets are increasing on the Fortigate - Check for decrypted packets on your end - As per revious comment - check if you can send traffic - Check the log to confirm the NAT is applied - Check for encrypted packets at your end and decrypted packets at Forti end ... View more

Hi Guys,   I have tried to accomplish something similar, but instead of filtering on expressRoute I wanted to filter on "required" JSON field.   It seems I have able to accomplish this, but I still don't understnad why you need to append "o365_" to the name of the JSON field:   infilters: - actions: - accept conditions: - __method == 'withdraw' name: accept withdraws - actions: - accept conditions: - type == 'URL' - o365_required == true name: accept required URL only - actions: - drop name: drop all whitelist_prefixes: - wl ... View more

That is great! Thank you @Remo,   This really give me some new hopes about our deployment and I will try to test it with valid license. For no it looks like that panorama mode must be used instead of the legacy.   Thank you once again! ... View more

Hi @Remo,   I am absolutly sure that I have PanOs 8.1.0. I can see that from the dashboard information. The only consurn that I have is that I deployed this VM in test lab - without license and it is running in legacy mode and i cannot whitch it to panorama mode (without license, which I am still waiting). The screenshot above gives me some new hopes! Can you please confirm to be: - Your Panorama is VM-Series? And Not physical appliance? - You are running 8.1? - You are running in panorama mode?   Really appreciate your feedback!! ... View more

Hi @LukeBullimore,   Thank you for your feedback! Indeed enabling the user identification under the zone object did the trick. I was mainly focused on establishing the redistribution and completely forgot about the zone configuration.   For whomever intersted, the complete step we did were: 1. On frontend firewall (the one with GP enabled) we have enabled User-ID redistribution (Device -> User ID-> User Mapping -> PAN user agent setup -> Redistribution 2. On frontend firewall, we have enabled User-ID on in the interface management profile for the interface facing the backend firewall 3. On backend firewall, we have configured frontend fw as user-id agent 4. On backend, we have add destination service route to use the interface facing the frontend firewall 5. On backend, we have enabled user-id on the zone where the GP users are hitting the backend 6. On the backend, we have configured GP IP pool in the include networks for the user-id, under the zone, to filter out all other traffic that doesn't have user-ip mapping   Luke, thanks again for prompt assistance! Best Regards ... View more

Hi @Remo   Interesting solution, but if I understand correctly basically your suggestion is to add the routes via script instead of the firewall sending. My concerns is that if we add the routes with the script what should we configure on the PA FW for routing? And more speficially if we add routes via script to send traffic via the tunnel, but in the firewall configuration we don't add these routes, wil firewall accept it? I have see with other vendors that "access routes" (the routes for split tunneling) are configured under VPN encryption domain and firewall will drop packet destine to address that is received by the tunnel, but not configured in the encryption domain.   @BPryUnfortunatelly it seems you are right...I was really hoping for more flexibal solution as I have seen this (RA VPN + Office365)  couple of times and when customer requst split-tunnel with this it is insane...   We have communicate this with the customer and the temporal solution will be to convert to full tunne, for permanent we will upgrade.   Thank you both for the feedback! ... View more

Have you seend this - https://live.paloaltonetworks.com/t5/Management-Articles/How-to-get-notifications-about-IPSec-tunnel-status/ta-p/65844   Not completely sure if it the absense of SNMP OIDs is still valid for current versions. ... View more

Hi yihhow,   This sound interesting, but little bit odd... DOS policy should be triggered by abnormal amount of traffic, I am curious how exactly simple RDP SYN triggered the dos protection. Also isn't dos protection actions recored in the logs? What debug did you use to identify the root cause?     ... View more

One more think - If you don't see logs for your attempts, please check if you have enabled log for default Intra and Inter zone security policy? If traffic doesn't match any explicit rule is probably being dropped by the default zone rules, and by default they are not logging. another you can check is  run test security-policy-match <fill in the rest> under the CLI ... View more

Of cource it wouldn't work...When using destination NAT, Security policy must contain PRE-NAT addresses and POST-NAT zones. Which means that your original configuration configuration is actually correct.   In my humble opinion your original configuration was correct (correct NAT and correct security policy). There was suggestion to set source NAT and I saw you have enabled source and destination - I would say this is wrong... I believe the suggestion was to configure source static nat and enable bidirectional. That way you should accomplish the same think create static NAT. But you shouldn't enable both source and destination in the same rule.   In the capture you can see that drop capture is filling with with the SYN, so   So my suggestion: 1. Put everything back as you configure it originally. 2. I saw that you are using service group RDP, can you confirm that this service group contain TCP port 3389? 3. Enable log on start for the security rule 4. Check traffic log for log matching your source address. send screenshot for this entry (you can hide the real addresses if you like)     ... View more