About mikand

Is it possible for you to split that /25 into smaller chunks? I mean if the TMG zone must use public ip addresses you can assign the first /26 for that. The second /26 will be used for outgoing SNAT (like internal-zone web.browsing) and/or incoming DNAT (going to your non-sharepoint sites sitting on WEB zone using RFC1918 addresses). Another option would of course be to use RFC1918 on all your DMZ's and then just SNAT/DNAT that /25 in whatever way you wish (assuming that 156.98.x.x is just a linknet between your PA and the ISP). Edit: See for hints on how to setup the NAT-rules and Security-policy. ... View more

What about using each PA box as a single device and use Panorama to configure them equaly? Perhaps more complex solution (since the router between your internal net and PA must decide which way to use) but will bring you twice the performance compared to using active/passive or active/active. ... View more

There are various setups described in these docs which I guess might be helpful in your case: Designing Networks with Palo Alto Networks Firewalls https://live.paloaltonetworks.com/docs/DOC-2561 Diagrams and Tested Configurations https://live.paloaltonetworks.com/docs/DOC-2560 Even if PA will work as "router on a stick" you will get better performance throughput if you utilize more than one cable for all your traffic (like a physical interface as inside and another as outside). If im not mistaken QoS doesnt work on aggregated interfaces today (I think this is already setup to be fixed in future releases) but this is only good to know if you will use QoS in your PA (otherwise you can let the routers do the QoS for you). You can also setup VSYS in PA to virtually split the dataplane for various uses (given that you trust stuff such as VRF and VSYS etc). When it comes to performance - instead of using your two PA's in a active/passive cluster (or active/active for asymmetric routing (note that the total performance is still the same of active/passive) you can configure them as two independent boxes and use panorama to make the configuration easier for the administrator. This way the routers can perform ECMP (Equal Cost MultiPath) to loadbalance between the two independent PA's (and make sure to use hash(srcip+dstip) as loadbalance algo) and by that you will get twice the performance through your PA "cluster". ... View more

The main difference between a transparent http-proxy and non-transparent http-proxy is how the request which the client sends looks like: transparent: GET /path/file.txt HTTP/1.0 Host: www.example.com non-transparent (aka forward-proxy): CONNECT http://www.example.com/path/file.txt HTTP/1.0 Also, when using a transparent proxy it will use the dstport on the inside as dstport on the outside. Which means that if you use a PA to DNAT the traffic from TCP80 into TCP8080 it will arrive to your proxy at TCP8080, the proxy (if runned in transparent mode) will then reuse the values of dstip and dstport on the packet it constructs on its outside before being sent to Internet (or whatever you might have there). Which gives that if you cannot force your clients to use a proxysetting (so they send CONNECT http://www.example.com/ HTTP/1.0 instead of GET / HTTP/1.0) then you need to change your transparent proxy to act on the port (TCP80 and usually also TCP443) which the client tries to connect to (which the client thinks is the server it will speak to but by routing it will actually speak to the proxy session-wise). ... View more

Since you dont have any vlans at all (just a physical lan) and probably wont be able to change how the access network looks like my idea was something like: 1) A regular interface, for example 192.168.0.254/24 (which you add in dhcp as default gw so regular clients will use 192.168.0.254 as default gw to reach Internet or whatever and before they are let out they must use the captive portal). 2) A subinterface (or another physical interface), 192.168.0.253/??, which the ssl-vpn clients would connect to. Its the last part which im not sure if its possible to accomplish on a PA (due to ip range collissions and such). As sdarapuneni said if you enable both captive portal and ssl-vpn on the same interface then the PA will force both to be valid (meaning ssl-vpn users would still get a captive portal). Im thinking if it would be possible to trick PA into this support by using vrouter and/or dnat/snat in combination? A workaround could be if you setup something like: 1) 192.168.0.254/24 for regular clients (captive portal) on int1. 2) 10.0.0.254/24 for ssl-vpn clients on int2. Connect both to your access network and in the dhcp put up static leases based on mac address. This way a regular client will get a 192.168.0.x ip and 192.168.0.254 as default gw and your known ipad (etc) clients gets a 10.0.0.x ip and 10.0.0.254 as default gw. Because this ip "separation" isnt a true separation (they are all on the same vlan anyway) the only way for a client who gets a 10-ip to reach internet is either to auth using ssl-vpn OR go through 192.168.0.254 and use the captive portal - either way they must authenticate in order to leave your access network. Of course this doesnt fulfill any demands regarding strong auth (since you use captive portal) but your case doesnt seem to involve being 100% sure of who did what (because in order to use captive portal your access network must be secured/hardedened aswell like using protected vlan so clients cannot steal each other ip/mac addresses and such but also since if a user gets hold of another users login/pass they will use that instead of their own) but rather make it easier for your trusted clients to use your access network. ... View more

Cannot one setup two interfaces (connected to each zone) where one interface is the regular captive portal (and default gw) and the other is ssl-vpn which your own devices (ipads etc) will connect directly to? And then in the security rules you set this as srczone: zone_portal, zone_vpn ... View more

I assume you have your ISA on a dedicated DMZ. Does this DMZ use the public ip-range or does it use a RFC1918 range (what is the ip address of the ISA box itself)? When you setup security rules in PA for NATed traffic the guideline is: srczone: <prenat srczone> dstzone: <postnat dstzone> dstip: <prenat dstip> So given that you use RFC1918 addresses in your DMZ you will setup a DNAT rule such as: srczone: outside dstzone: outside dstint: any src: any dst: <ip of your PA at outside zone> service: TCP443 (or the list of ports you need to get translated for inbound connections) srctrans: dsttrans: <ip of your ISA> and security rule like: srczone: outside dstzone: dmz dstip: <ip of your PA at outside zone> service: TCP443 (or a list of ports or application-default, I recommend to never use any) appid: ssl (or which appids you need) Personally I would avoid using "bidirectional" and instead manually setup DNAT and SNAT when I need (and limit to specific ports if possible). In your case are you sure your ISA needs to be able to on its own connect to Internet (or whatever you have on your outside)? 1) See above 😉 2) Im not sure how much ISA is involved in the OWA/OMA stuff. I think ISA is capable of do a first certificate verification which the Exchange doesnt do but that could have been changed (Microsoft seems to change this behaviour for every release). Edit: Since most traffic for OWA/OMA is https-based I would strongly recommend you to use ssl termination in the PA in order to be able to inspect the content of the ssl sessions (and using the PA IPS, AV, FILE and such features). ... View more

Is this a hard limit due to restrictions in pfga/asics being used or is this a software limit (which PA, after a feature request, could make larger for lets say PA-5xxx series)? ... View more

PA uses top-down first-match (which I prefer over the other method used by freebsd and older allied telesis equipment where a later rule could "win" over a previous rule). ... View more

Q: Restricting traffic to particular ports doesn't allow the PA to do its application signature thing (does it). A: Incorrect. The application signature works at all time, however what you define in the service column will of course be the first tests to the traffic (if srczone/srcip/dstzone/dstip/service doesnt match the traffic wont be checked for appid). I would strongly recommend you to NEVER set service=any but rather service=application-default or, if possible, set it to the ports you really need. For example TCP22 for appid=ssh (if you run your ssh-server at TCP22 that is). Q: On the other hand an "any application, on any port" policy seems to be a bit too permissive. A: Yes and you need to keep that in mind. Depending on protocol it can take two or more packets in each direction before the appid is successfully identified (this is why I strongly recommend anyone to NOT use service=any). One way to limit the effects is if you (as one of the first rules) setup an action=deny for traffic identified as appid=unknown, unknown-tcp, unknown-udp, unknown-p2p. Q: Are there supersets of applications? A: Not that im aware of out of the blue (uhh scratch that, you can use application filtering to use supersets of applications since applications are classified into categories, subcategories and risks). When it comes to appid thats one of the tricky things to learn when it comes to a NGFW. In PA case a flow/session can only be identified as one appid at a time (but it can switch appid during its lifetime). This gives that if you allow only web-browsing (and nothing else) and visit youtube (which has its own appid) - when the appid switches from web-browsing into youtube the traffic will be blocked (unless you allow youtube or an application filter where youtube is included in). Q: Do web-browsing and ssl include say google and gmail?  If not what do they allow exactly? A: Se above. The will identify web-browsing which isnt already identified as some other app. Same with ssl. If the traffic is gmail the identified appid will be gmail. But if the traffic is a new ssl based communication which PA currently doesnt have an appid for the result will be that the flow/session is identified as ssl. Workarounds: 1) Do what Sandeep described. Setup an application filter where webbased applications are included along with appid=web-browsing. If you combine this with an action=deny for unknown traffic then only webbased traffic which the PA can identify will be able to pass through. 2) Another method (if you still want to allow unknown for some reason) is to create an IPS signature that will block traffic if the request doesnt contain http-method=GET||HEAD||POST (or whatever http methods you wish to allow). ... View more

Depends on which IPSec mode aswell... ESP (tunnel mode - full packet is encrypted and given a new header) or AH (transport mode - only payload is encrypted, keeping original header regarding srcip, dstip etc)? Also given the findings of BEAST and now recently CRIME there could be situations where choosing SSL-VPN wont be such a good option after all. ... View more

So still no detection as gmail-drive (the correct detection is still google-drive-web)? ... View more

Sorry you are right, if the traffic log identified the traffic as ssl or whatever then it wont help by adding gmail-drive If possible (during "debug") you can use "any" as appid to spot how the PA will detect the traffic (limit the rule to the specific client ip as srcip or such) - would be nice if you could return with info on how the PA detect the traffic once you enabled ssl termination. ... View more

What about if you add gmail-drive (which seems to be what applipedia currently calls it)? 327-1497 is the latest db released 4th sept so your device seems to be up2date. I think you would also need to enable ssl termination (decrypt rules for ssl) in order to successfully block various google services. ... View more