About mikand

Yeah that was what first comes to mind... using RDP over Internet for sensitive data... are you nuts? :smileygrin: VPN seems to be the proper way to handle this. Which will also include authentication of the client ip before it can even handshake a RDP session with the servers. If im not mistaken there is a "free of charge" PA Globalprotect Client which you can enable in your PA device in order to use SSL-VPN (this free client is limited to only do the SSL VPN stuff - the other nifty stuff of Globalprotect is not included until you throw some money at PAN for a license). Your sales person will point their browser to your PA ip address (or dns entry pointing to your ip) and after login they will have a javabased SSL running between their box and your PA. Then they will be able to (through the VPN tunnel) access your RDP servers. A hint here (even if it will cost some more money) is to integrate the authentication stuff with some sort of OTP solution. Nordic-Edge (among others) have such solutions, look here for a video explaining of how it works: http://nordicedge.se/2010/06/11/palo-alto-networks-integration-till-nordic-edge-one-time-password-server/ ... View more

I assume that you have already setup the "service" part for each security rule so it will only allow the ip and port which is expected and then the appid is applied to only allow correct application through that port? I mean so you dont use "service:any" for all your rules? This way only legitime clients can use legitime ports on legitime servers using legitime application Which also gives that if a non authorized client attempts to connect their attempt will simply be denied (and logged if you enable logging of denied connections). ... View more

Or combine "my" idea with the one which www.cc.com.pl presented? Let the server use whatever private ip it currently uses but add public ip's from each ISP as subinterfaces on the servers? On the other hand I dont know how many subinterfaces the PA device will support without going for VLAN tagging. ... View more

How come this cannot be done through Panorama? ... View more

Login in with CLI and look if you have any pending failed jobs that might block your update? Also when you want to upgrade into 4.1.x from 4.0.x or older you should first install 4.1.0 and then reboot followed by installing the latest in the 4.1 branch (I think its currently 4.1.4). ... View more

After you upload, do you perform a commit? Which browser do you use? I think I saw something similar in another thread where uploading (or if it was downloading) from the admin gui was buggy with some browser. Unfortunately I dont remember if this was fixed and if so in which version. ... View more

Do you have vsys enabled and are you expecting to run vsys? ... View more

How often did you set it to reload? Because every time the dashboard reloads the auth session timeout should reset the countdown. Could there perhaps be some other timeout in your browser causing these problems? For example how long is your ssl repository open for access as timeout? ... View more

The PA doesnt do web proxy so it will not understand when a client connects to the ip address of the PA box and sends "CONNECT http://www.example.com/ HTTP/1.0". If you want to keep the proxy setting in your clients (well browser settings) and in order to avoid having public ip addresses in your internal network you would need to use a dedicated forward proxy for this. A good (and cheap) solution is to use squid. There are also squid appliances if you want to pay some money: http://www.squid-cache.org/Support/products.html Otherwise you need to disable the proxysetting in your client-browsers and make sure to point defgw towards your PA box (for the client the defgw is most likely already some router, then you need to add a routing entry in this router to point towards PA as defgw). Edit: A tip when using a forward webproxy inline with a PA is to setup the webproxy to use "keep client ip". Then the PA will get the client ip's (as srcip on the packets forwarded to the PA) and you can use the ACC in the PA device to dig on what each client have done (otherwise the PA would just see the ip of the webproxy). ... View more

Ahh yes sorry, was thinking of something else. "Vuln protection" in PAN is the IDP engine which acts at session-control level (just dropping the packets or sending tcp-rst's to make server and/or client to drop the connection). Current possible response pages seems to be (which you also can make your own versions of): - Default Antivirus Response Page - Default Application Block Page - Default File Blocking Block Page - Default URL Filtering Response Page - Default Anti-Spyware Download Response Page - Default Decryption Opt-out Response Page - Captive Portal Comfort Page - URL Filtering Continue and Override Page - SSL VPN Login Page - SSL Certificate Revoked Notify Page ... View more

Regarding your OWA question... does your clients have dns servers set who are available on untrust (who are blocked)? Because your description fits that a client tries to resolve something with dns1, fails after 2 seconds, tries dns2, fails after 2 seconds and so on until some more time have passed and the browser/sshclient/whatever just figures out "ehh, this doesnt work" and then continue with whatever it was trying to access. ... View more

The 2nd part depends on which of PBF and NAT is done first internally. If NAT is done before PBF then it will work - otherwise it will fail. Using a SNAT/DNAT combo might work but it will add complexity to your solution :smileysilly: (and you will lose statistics in the server logs regarding which client did what on your servers and so on). Another method could be if you could avoid NAT and set your servers in DMZ to be multihomed. Lets say ISP1 gives you 1.1.1.0/24 and ISP2 gives you 2.2.2.0/24 and from this you use the first /29 for DMZ. This way server1 at DMZ would have ip's: 1.1.1.1/29, defgw 1.1.1.6 2.2.2.1/29, defgw 2.2.2.6 This way we wont need to worry about if NAT or PBF is being done first since all thats left is PBF to take care of in your PAN. Not only that you wont need to do DNAT for incoming traffic but the returning traffic will be much easier to setup for the PBF: Setup a PBF for outgoing traffic for ISP1 from DMZ: srczone: DMZ srcip: 1.1.1.0/29 action: Forward (1.1.1.254, or whatever ip nexthop for ISP1 have) Setup a PBF for outgoing traffic for ISP2 from DMZ: srczone: DMZ srcip: 2.2.2.0/29 action: Forward (2.2.2.254, or whatever ip nexthop for ISP2 have) I think you could then also remove the PBF you already have and setup which ISP to use in your vrouter configuration instead (set ISP1 with lower metric than ISP2 if ISP1 is the prefered one for clients to use - PBF will override whatever vrouter says). ... View more

Good question... I hope someone from PA could answer if PBF will overrule any internal "express forwarding" (or what we might call it) or if the "express forwarding" will overrule the PBF for returning traffic. I think something like this might work: For your DMZ use some private ip range (just an example): 10.0.0.0/24 (in real life you would probably choose a smaller range than /24 aswell :smileysilly:). Setup a D-NAT for incoming traffic from ISP1: srczone: ISP1 dstip: 1.1.1.0/24 (or whatever ip/range it might be) dnat: 10.0.0.0/24 (the DMZ ip/range) Setup a D-NAT for incoming traffic from ISP2: srczone: ISP2 dstip: 2.2.2.0/24 (or whatever ip/range it might be) dnat: 10.0.0.0/24 (the DMZ ip/range) if the above wont work (lets assume since your PBF for ISP1 vs IPS2 will overrule which path the return traffic will take) you can add: Setup a PBF for outgoing traffic for ISP1 from DMZ: srczone: DMZ srcip: 1.1.1.0/24 (now I assume that NAT will be done before PBF) action: Forward (1.1.1.254, or whatever ip nexthop for ISP1 have) Setup a PBF for outgoing traffic for ISP2 from DMZ: srczone: DMZ srcip: 2.2.2.0/24 (now I assume that NAT will be done before PBF) action: Forward (2.2.2.254, or whatever ip nexthop for ISP1 have) ... View more

Regarding your first question a workaround might be to use static arp for each ip. But this will fail if a particular client can get different ip's depending on when it connected physically to your network. And I dont think PA currently supports a mapping between the internal DHCP server and security rules - you might need to contact your Sales rep to file this as a feature request. As a sidenote I strongly believe that these kind of operations should be taken care of by the network itself and not the firewall. Meaning that you should use dhcp-snopping (along with option82 including dynamic acl which means that the dhcp snooping in your switch will setup an acl to only allow the ip which the dhcp server told the client to use on a particular interface) preferly along with protected vlan (to isolate clients from each other). This way if a client who doesnt use dhcp connects to your switch it wont be able to speak to anyone. Those clients who connects and get an ip address then only this ip (per interface) will be able to communicate to your PAN (assuming your design is PAN <-> switch <-> clients). ... View more

A dirty temporary workaround (just to upload the file) would be if you add another mgmt interface on of the dataplane interfaces (and once uploaded and all that remove that mgmt interface). ... View more