- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
04-04-2012 03:59 PM
We are in the process of switching from a T1 provider to a fiber connection through another ISP. The T1 provider has us on a /29 network where they provide a router which occupies the first usable IP of the range. Our new ISP has the outside interface on our PA-500 connecting directly to a switch. We were given two ranges of IP addresses: a /30 which contains the address we're supposed to assign to the outside interface for OUTBOUND traffic, and a /29 which contains our six usable addresses we're supposed to use for inbound connections. I've provided a diagram with anonymized addresses to show the topology.
/29:
10.1.76.4 = network address
10.1.76.5 = the address of their router
10.1.76.6 = the address they advised we assign to the outside interface of our PA-500
/30:
10.0.194.112 = network address
10.0.194.113-118 = usable IP range
We wish to set up the following on the usable IP addresses and tie them to the outside interface of the PA-500:
Terminate 5 IPSec VPN connections from remote sites
Host a Palo Alto NetConnect SSL VPN
Point an A record to a remote access server (NAT)
Point MX and A records to our email server (NAT)
Reroute all outbound internet traffic through the new ISP
I'm trying to set up the IPSec VPNs first. I assigned the 10.1.76.6/30 address to the outside interface on the PA-500, and I'm able to ping it from the Internet and can use that address to terminate IPSec VPNs. I couldn't ping any of the usable 10.0.194.### addresses until I set them up as loopback addresses in the PA-500. I was then able to ping them, but couldn't terminate my IPSec VPN tunnel on any of them.
My NAT policy for the IPSec VPNs is zone-based, and I set up the interface identically (in terms of zone membership) to the interface that's hooked up to our old T1 line.
So, I guess my questions would be:
Do I need the loopback settings, or just the NAT rules? Should I be terminating things like IPSec VPNs, NetConnect, and our Internet PAT on that 10.1.76.6 address, and then just use that /29 range for MX and A records for internal NATted devices? Is there otherwise a way to get everything, including IPSec and NetConnect routed over that /29 range?
Thank you for reading through this lengthy explanation. Any assistance would be greatly appreciated.
-KW
04-09-2012 01:38 PM
Hello
You'd need the NAT rules to be able to address your MX records
For IPSEC you can terminate your tunnels on the loopback interfaces
Ideally you want to keep your NETCONNECT and IPSEC connections on two different IP addresses, so terminate the IPSEC on loopbacks
and you can terminate the NETCONNECT on the actual interface IP
So long as you have NAT rules configured and traffic is being routed to your PAN FW, you can just configure the incoming connections and NAT them down to your internal servers
Hope this helps
04-09-2012 03:49 PM
Also I think kwarner23 missplaced the /29 and /30 networks in the first post.
The /30 (if we speak IPv4) has 4 ip addresses (2 usable) and is in these situations often refered to as the "linknet" (or "link network"). Not uncommon that the linknet is using a private ip range (RFC918 - which means that it isnt (or shouldnt be) accessible from another ISP).
While the /29 has 8 ip addresses (6 usable) and is often called the "routed network". Not uncommon that this routed network is a set of public ip addresses so it is accessible from other ISPs.
This gives that in your router (well PAN in your case) you setup it to use ip 10.1.76.6 mask 255.255.255.252 (/30) with 10.1.76.5 as defgw. And your ISP will set 10.1.76.6 as nexthop for 10.0.194.112/29 (which then they announce in their network as a valid range and to which distrouter it belongs to).
So if your linknet is using public ip addresses then I would use the PAN ip address to terminate the incoming encryped VPN-tunnels (unless you use a dedicated box for this sitting on a DMZ but then you would use one of the routed addresses for this). Otherwise you could (I think) setup one of the /29 addresses as localinterface with mask /32 and let the other VPN hosts connect to this ip (this way the PAN will still handle the VPN-connections - again unless you use a dedicated box for this in a DMZ).
Also I guess that 10.0.194.112/29 was just an example from your side since this range aint routable over the Internet (on the other hand perhaps it isnt the Internet you are connected to)?
If the /29 is a range of public addresses I would avoid using NAT if possible (on the other hand you would then lose 2 addresses as net/broadcast if you for example use 10.0.194.112/30 as DMZ and 10.0.194.116/30 as outgoing SNAT addresses for surfing or whatever)..
04-09-2012 03:50 PM
Hello,
I am currently out of the office and will be returning on Thursday, April 12, 2012.
If you need immediate assistance, please contact the COMPUTERLINKS Technical Support group via phone at +1 512 672 8903; or by using the appropriate support phone number within your support contract.
Thank you,
Darren Sharenko
Sales Engineer
COMPUTERLINKS North America
11500 Metric Blvd, Suite 300
Austin, TX 78758
T: 1 512 672 8903
darren.sharenko@computerlinks.com
www.computerlinks.com
04-09-2012 04:02 PM
Ehm... is it possible for someone from PAN to disable this magic SMTP interaction which this forum seems to have since autoreplies are posted directly into the threads (for obviously no use)?
04-10-2012 01:04 PM
Thank you for your reply. I am starting by attempting to migrate my IPSec tunnels from our old ISP to the new one. I can successfully terminate the tunnels on the IP of the physical interface (in this example it was 10.1.76.6), but when I attempt to terminate on a loopback address (in this example 10.0.194.118), the remote Cisco ASA gets stuck during phase 1 of the key exchange with a "MM_WAIT_MSG2" error. I tried re-entering the pre-shared key on both ends, but that didn't work.
My policies (NAT and Security) that pertain to the IPSec VPNs specifically are pretty simple.
NAT
Name = No_NAT, Source zone = any, Dest. zone = any, Dest. Address = 192.168.192.0/24 (the private range of the remote network). On the physical interface, I hadn't had any source or destination translations set up, and wouldn't think I'd have to, given that the VPN is terminating on the outside of the firewall.
Security
Permit anything into Trust zone or DMZ zone (zones that live "behind" the firewall) from VPN zone (zone that encompasses the IP ranges of all of the remote networks that connect via IPSec VPN).
So I can see how NAT will work when I'm moving MX and A records, but terminating IPSec on the loopback is so far proving problematic.
04-10-2012 01:12 PM
Thanks for your reply. I did transpose the /29 and /30 as you'd suggested. It's correct in my diagram, but wrong in my text. You're also correct that I've anonymized the IPs and my example uses a private range.
My first step has been to start migrating the IPSec VPNs over to the new ISP. I've been successful in putting those onto the IP of the physical interface (in this example 10.1.76.6), but have thus far been unable to get those onto a loopback address (in this example, I'm attempting 10.0.194.118). I would be comfortable terminating those IPSec VPNs on the 10.1.76.6 address, but another respondent recommended putting these onto one of the loopback interfaces and saving the physical interface IP for NetConnect. In hindsight, though, with our old ISP, we've had NetConnect and the IPSec tunnels terminated on the same IP address on a physical interface. So maybe I could just terminate NetConnect and the IPSec VPNs on the physical IP, and then just save the loopbacks for my NAT translations?
04-10-2012 02:37 PM
Yes you can terminate both the IPSEC and NETconnect onto the same physical interface - one will use ssl and the other IPSEC so you should be ok.
If you create NAT rules using those IP addresses - you *should not need any loopbacks and the PAN FW should just proxy for those IP addresses for which is has the NAT rules.
Hope this helps
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!