Can AOS create a Cisco VTI-style IPSec tunnel (*not* GRE-in-IPSec)?

[Anonymous]

I have a Palo Alto firewall at our corporate HQ, which supposedly (per their discussion forums) cannot handle GRE inside IPSec.  However, Palo Alto does support a Cisco-style "VTI" tunnel, where each endpoint has a "tunnel.x" endpoint with its own IP address, allowing multiple subnets of traffic to be routed across IPSec without requiring multiple IPSec Proxy IDs.  I'm using an NV3120 at the remote site.

Other than the Adtran-documented GRE-in-IPSec solution (Configuring a GRE over IPSEC VPN Tunnel in AOS), is it possible to configure a VTI-style VPN on AOS?  I have multiple subnets at the remote site and I'm trying to avoid multiple ProxyID entries (the Palo Alto has a finite limit on the number of Proxy IDs it supports).  I don't actually need or care about the dynamic routing aspect of this style of configuration.

Attached is Palo Alto's guide to configure this style of tunnel, in case it helps.

[Anonymous]

Hi zprime:

I don't know of a tunneling protocol other than GRE that you could use to create a routed interface in AOS.  One approach to keep IPsec SAs (proxy IDs) to a minimum is to use one supernet for VPN selectors to encompass several/all of the subnets you need to reach from the remote site.  This works well when your subnets all fit within a single larger class network range.  For example, you use 192.168.0.0/24 for Site A, 192.168.1.0/24 for Site B, and 192.168.2.0/24 for Site C.  Your selectors could allow 192.168.0.0/16 to pass traffic over a single IPsec SA.

Your actual subnets may or may not fit cleanly within one supernet selector, but even if you can summarize into a couple or relative few selectors, it will keep active IPsec SAs low compared to a selector for every subnet.

Maybe not the answer you're looking for.  Hopefully you can fit things together in a workable manner.  GRE over VPN to another AOS device at the main office would be a nice clean way to go, of course, with a single static route in your Palo Alto to the local device as its gateway to the remote site.

Best,

Chris

[Anonymous]

Chris,

I'm already doing what you suggest - our corporate site uses two non-contiguous blocks, a /23 and /24, and we have other remote sites (MPLS) that are on additional non-contiguous /24s, but both non-contiguous ranges can be summarized into a pair of /16s.  I summarize everything with proxyIDs of 192.168.0.0/16 and 10.0.0.0/16 for the HQ side.  In this case, the remote site uses 192.168.148.0/24 and 10.0.148.0/24.  However, to allow all traffic to/from all subnets is still 4 ProxyIDs / IPSec SAs, I was hoping to have it down to one, but if it's not possible then we just have to live with it.

That aside, I'm also noticing problems bringing the SAs up for each ProxyID.  All of the SAs will come up if I initiate the traffic from the Adtran/remote side, but when I try to bring up an SA from corporate it doesn't seem to work.  The main SAs - 192.168.148.0/24 -> 192.168.0.0/16, and 10.0.148.0/24 -> 10.0.0.0/24 -- come up readily because there is usually traffic trying to go that way from the remote site.  The problem is if I need to access something on 10.0.148.0/24 from the corporate 192.168.0.0/23 range (which is obviously covered by 192.168.0.0/16).  When I start a ping from 192.168.x.x to 10.0.148.1, the tunnel never comes up.  If I flip that and start the ping from 10.0.148.1 back to 192.168.x.x, the SA fires up and traffic works bidirectionally.

Both sides are in Main mode, both sides are static IPs, and both sides have Local ID and Peer ID configured (using IP address IDs).  On the Palo Alto, I have 4 ProxyIDs configured - two with "Local" of 192.168.0.0/16 and remote of 192.168.148.0/24 and 10.0.148.0/24, and then another two with Local of 10.0.0.0/16 and the same remote subnets.  On Adtran, I just have the "allowed local subnets" of the router's two /24 ranges, and "allowed remote destinations" of both /16s.  I can supply configs if that would help, I'd have to sanitize out the public IPs but I don't care about the RFC1918 ranges being aired. 

I'm not sure where to start looking to troubleshoot this?  Thankfully I can tear down & rebuild (for testing) the SA between 10.0.148.0/24 and 192.168.0.0/16 without any major business impact - it's pretty rare that we need this traffic, but I'd like to make sure that both sides can correctly initiate any/all of the SAs!

[Anonymous]

To get everything up and working, you could use a ping probe in the remote AOS unit to keep the SA active.  Maybe:

!

probe VPN-Activator icmp-echo

  destination 192.168.0.1

  source-address 10.0.148.1

  period 60

  no shutdown

!

Use whatever hosts are valid.  This is a hack, I guess, and it might be best to figure out why SAs can be opened only in one direction.  It may have something to do with the selectors or policies in the ADTRAN.  If you think it might help, post your config (sanitized of serial numbers, passwords and public IP addresses) and we can take a look.

Chris