I'm sure this is easy on our PA850 firewall but I can't figure it out.
I need to have outbound internet access from 4 internal IP addresses destined for one specific internet IP to use a specific physical WAN interface (ethernet 1/6) and associated static IP address. Our default outbound interface, associated IP address and NAT rule is currently on ethernet1/5.
The aim is to dedicate the entire bandwidth of the WAN link on ethernet1/6 for replication traffic out to this one specific address, only from these 4 internal servers.
I thought I had sussed it by just setting up an outbound NAT rule (above our default outbound NAT rule) as follows:
When looking at the Session Monitor I can see the translation works and that the static IP address is in fact a WAN IP assigned to ethernet1/6 but that the egress interface is still ethernet1/5. Strangely the traffic still works but its obviously using massive bandwidth on the wrong interface?
Any bright ideas or am I missing something obvious with static routes on the default virtual router?
Your NAT is correct and you still need it in order to have reply back via the correct ISP. But you still need routing. Think about it - routing desicions is based on the destination address. If you change/NAT the source IP of the packet that wouldn't make any difference for the route lookup.
I noticed in your NAT rule that you have specific Internet IPs as destination. If you have limit number of addresses that you already know you can simply create static routes for those hosts pointing the next-hop via eth1/6, next to your default pointing to eth1/5.
But this approach can quickly because hard to manage if you start adding more and more addresses that needs to be routed via secondary ISP - eth1/6. This is where the PBF come in handy. With PBF you can tell that anything sourced from these four addresses, to any destination should be routed via eth1/6 (you can even specify ports based on your requirements). In this case you don't need to create multiple host static routes pointing to eth1/6.
Read more in the document from @BPry
Thank you both for your replies, most helpful.
I did wonder about the routing table and whether that would need amending. I looked at PBF for another situation but the requirement went away so never got to test it out.
As far as routing goes, on our single virtual router, I have the two default 0.0.0.0/0 routes for each WAN interface with their associated next hop IP address and the metric is lower for ethernet1/5, which explains why the traffic is hitting that interface along with regular internet access, despite the new NAT rule. What I didn't understand is how the server out on the internet does show the desired outbound IP hitting their firewall, despite it being the wrong IP for the wrong interface. Is it spoofing that IP somehow?? The traffic is definitely heading out of the 'wrong' interface though.
Sounds like PBF may actually be the quicker and easier way forward for this? I could actually set it up for that all internet traffic from these specific internal addresses follows the alternative WAN interface. It doesn't need to be just for that one destination internet IP.
What I didn't understand is how the server out on the internet does show the desired outbound IP hitting their firewall, despite it being the wrong IP for the wrong interface. Is it spoofing that IP somehow?? The traffic is definitely heading out of the 'wrong' interface though.
Are both connections through the same ISP? I've seen before where an ISP will allow you to send traffic through either interface and they'll simply route anyways. I'm guessing you don't see any return traffic when you set it up like this, as the ISP would route it back through the proper interface on their end.
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!