- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
03-24-2011 08:47 AM
As somewhat of a newby to PAN, I need to ask how do I go about passing an internal public IP range outbound through the firewall and NOT natting it. This certain range of addresses will only connect to one other public IP address (different, external network) but the other address needs to be able to see these internal IP 's for what they are and not be natted.
Thanks! Mike
03-24-2011 09:10 AM
Hi Mike,
You can exempt certain IP's or subnets from NAT by keeping the Source and Destination Translation fields as "none"
Cheers,
Kelly
03-24-2011 09:10 AM
Hi Mike,
You can exempt certain IP's or subnets from NAT by keeping the Source and Destination Translation fields as "none"
Cheers,
Kelly
03-24-2011 10:00 AM
Yeah, this sounds like what I need to do. If I set the source address to that of my internal range and the destination address to that of my target server, then the "no-natting' should only occur between those two sets of addresses, right? Any extra Security policy rules needed( (other than what I already have in place)?
03-24-2011 10:07 AM
You got it. You shouldn't need any other policy entries beyond what you would normally have in your Security Policy to allow the two segments to communicate.
Cheers,
Kelly
03-24-2011 02:29 PM
Should that new NO NAT rule be placed above the normal outbound PAT rule everyone else on the network is using?
03-24-2011 02:32 PM
Absolutely - all policy rules are evaluated top down and terminate on match.
Cheers,
Kelly
03-24-2011 04:18 PM
mwaters31 wrote:
As somewhat of a newby to PAN, I need to ask how do I go about passing an internal public IP range outbound through the firewall and NOT natting it. This certain range of addresses will only connect to one other public IP address (different, external network) but the other address needs to be able to see these internal IP 's for what they are and not be natted.
Thanks! Mike
Are your "internal" addresses RFC1918, and your external "live" Internet addresses? If so, I don't see how you're going to get your "inside" addresses routed by your external provider - ISP edge routers should be configured, by default, to drop anything from or two an RFC 1918 address range.
Enquiring mind wants to know. 🙂
If your "internal" adresses are live, routable addresses then my question is probably invalid - also similarly invalid if your "external" link is some form of point-to-point link which only uses RFC1918 addressing in the path.
Cheers
03-25-2011 09:01 AM
The internal addresses of which I speak are in fact, live public addresses. These are a small network that is part of a VPN server in which the server hands out addresses in this range to remote(Internet) clients that request them. These addresses are then used to connect to the target IP address I mentioned earlier.
We were having some issues where when two or more vpn clients were connected, each one would lose its connection every 30 seconds, then regain it again. Another agency (we are a city) had experienced the same issue and they resolved it by removing the natting their firewall was doing for their vpn clients.
Funny thing is, after I inserted the new "no nat" rule, I still wasn't seeing any traffic matching the rule in the Traffic logs. The client "problem" had seemed to go away as well. Success I thought. Then I thought I would disable the new no nat rule to see if I could make the problem occur again. Well, the problem didn't occur again and the clients kept operating normally. So now I don't know if the new rule did anything or not. Weird.
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!