How do I configure an external interface for a direct fiber (metro ethernet) connection?

Showing results for 
Show  only  | Search instead for 
Did you mean: 
Please sign in to see details of an important advisory in our Customer Advisories area.

How do I configure an external interface for a direct fiber (metro ethernet) connection?

Not applicable

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: = network address = the address of their router = the address they advised we assign to the outside interface of our PA-500

/30: = network address = 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 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 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.



L4 Transporter


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

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 mask (/30) with as defgw. And your ISP will set as nexthop for (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 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 as DMZ and as outgoing SNAT addresses for surfing or whatever)..


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


11500 Metric Blvd, Suite 300

Austin, TX 78758

T: 1 512 672 8903

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)?

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, but when I attempt to terminate on a loopback address (in this example, 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.


Name = No_NAT, Source zone = any, Dest. zone = any, Dest. Address = (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.


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.

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, but have thus far been unable to get those onto a loopback address (in this example, I'm attempting  I would be comfortable terminating those IPSec VPNs on the 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?

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

  • 7 replies
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!