Does anyone know of any good documentation that explains how to set up dual ISP's into my PA-500 device? I currently have a single T1 running into the PA-500, but am going to be adding a cable connection within the next couple weeks. I would like to use the Cable Connection for all Internet surfing, and the T-1 for E-mail and such.
Can this be done? I found a few posts that say it can be, but didn't come across any good documentation as to how I can set this up.
Any help would be greatly appreciated.
I do the same - it works really well.
I have PBR rules sending different types of traffic to different ISPs.
Make sure you NAT your outgoing traffic src address to the correct ISP IP (use destination interface in NAT rule) to ensure that the traffic comes back down the correct link!
I have to route different types of traffic through 2 ISP and I need to use PBF rules with monitor (because I will check if ISP is on beyond the next-hop) and one default-route e.g. on the first ISP. But if the first ISP fails I need route all traffic to the second, and viceversa, if the second ISP fails I need route all traffic to the first. How can I configure default-route and PBF rules with monitor to get this behaviour ?
Let's say we want port80 to go out ISP1 with ISP2 as backup, and port443 to go to ISP2 with ISP1 as backup. ISP1 has IP 184.108.40.206 and ISP2 has IP 220.127.116.11. We can define 4 PBF rules:
for port 80 traffic:
rule1-ISP1 forward traffic=port 80 to 18.104.22.168, monitor 22.214.171.124, disable-if-unreachable
rule2-ISP2 forward traffic=port 80 to 126.96.36.199, monitor 188.8.131.52, disable-if-unreachable
for port443 traffic:
rule3-ISP2 forward traffic=port 443 to 184.108.40.206, monitor 220.127.116.11, disable-if-unreachable
rule4-ISP1 forward traffic=port 443 to 18.104.22.168, monitor 22.214.171.124, disable-if-unreachable
When both ISPs are up, port80 traffic will match rule1 before rule2 and always take ISP1. If ISP1 is down, rule1 will be disabled and traffic will then match rule2 taking traffic to ISP2. The option 'disable-if-unreachable' will permit the next PBF rule to kick in.
Question- I have 2 ISPs connected to a cisco7200, then pass down to my PA2020. is there a way to have a primary and secondary ISP setup.
So if the PrimaryISP goes offline my NATs will fail because there IPs are from PrimaryISP, but I still want my users inside to be able to get internet out thru SecondaryIPS.
Both ISPs are connected to the same 7200.(they used to NAT /Overload with it, we are moving to the PA2020) and we dont have any dynamic routing or BGP.
I was thinking of setting up BGP but we will be moving all the server out of this location so we just need to get a backup ISP working. I have seen the documents about dual ISP but there connected directly to the PA.
@ dave the ISP might be able to move, but not now.. we are migration to the PA2020 from a software firewall with NATs on cisco7200, also we have a VPN hosted off the 7200. there might be some PBR on the 7200 but if the PA has an easy way that would be better. the link between the PA and 7200 is using Public IPs
@ rmonvon that is a good idea, I will have to look closer at that option. I could move the ISP2 connection from the 7200 and down to the PA becuase that is the only system that would need dual IPS.
We are having two ISPs for our internet and PBF is configured and working fine. We want to put a proxy solution in place for caching (TMG) but not sure where to put it. If I place proxy outside the firewall in a different zone then how it is going to switch between the two lines.
You can and should give your proxy two interfaces, one outer and one inner interface.
Which means if you only have one switch then create two vlans, one outer vlan and one inner vlan which both ends up in their own zone in the PA box.
Another method, for performance reasons (because the above will use 2 sessions in your PA box for every session going through the proxy) is to physically place the proxy inline with the PA unit on its dedicated interface.
That is if you still need to have traffic NOT going through the proxy (like incoming email from dmz) you can set it up as:
PA: int1 (Internet)
PA: int2 (DMZ)
PA: int3 (internal network)
PA: int4 (proxy_int1)
Proxy: int1 (PA_int4)
Proxy: int2 (internal network)
Then on the link between PA and proxy you use whatever RFC1918 range you prefer, for example:
The clients will then setup in their browsers to use the internal ip (int2) of proxy.
The firewall settings in PA will block clients trying to go out through int3 of the PA box (only for example the mailserver communicating with DMZ should be allowed here, and things like NTP etc).
The nice thing with above is that you in the proxy can setup "reflect client-ip" or "keepsource=yes" or whatever the setting might be called. That is the headers of the ip-packets leaving the proxy towards PA will have the client ip set as srcip and you can in PA now have proper logs but also use userid. The NAT will be performed by the PA.
A workaround is to use the X-Forwarded-For header but that will leak info of the internal client to the internet but also only be used in the userid field (since the srcip in this case is the proxy ip). Yes there is a way to clear the XFF header in PA but that is only partial and it seems that some IPS out there will trigger the incorrect header as a threat.
If you still prefer to have your proxy in DMZ you have various options on how to physically connect it but still maintain an outer/inner topology.
One way (instead of one physical interface for outer and one for inner) is to aggregate the interfaces into etherchannel/lacp towards the switch and then use vlans towards the PA. That is in the proxy you will have one outer vlan and one inner vlan. This way you get some redundancy incase one interface dies.
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!