Sdwan edge device and ASA behind it

[Steven Williams]

We are gearing up the whole SDWAN thing and I am being told the dual DIA circuits need to terminate at the sdwan edge device, but I need to keep my firewalls behind this device for compliance reasons. Well I have always done the NAT at the ASA, so how does this change things? Will my public IPs be on my ASA anymore? Do you just run a /29 or /28 between the edge sdwan device and ASA and nat again at the ASA? This driving me nuts! Last implementation of sdwan I did we pulled the remote branches into the DC on a head in unit that had a different isp. We backhauled all sites to dc then out to the internet so my internet edge was still traditional when it comes to nat on firewalls. This place wants to make sdwan devices the edge routers and firewalls in one but I can’t do that for compliance so how does this design work? 

[stefan.radovanovici]

What "compliance" requirement doesn't the vedge (I assume you're talking about Viptela) satisfy but the ASA does ?

[Steven Williams]

PCI DSS and PCI Card Production. Firewalls need to be physically separate devices that segment certain parts of the network. Requirements are also IPS/IDS inspection thus the need for sourcefire.

[stefan.radovanovici]

The vedge can definitely do segmentation and even IPS/IDS in the latest version. We use vedges at the network edge in retail locations and they are PCIDSS compliant. 

[Steven Williams]

PCI DSS is one thing, PCI card production is bit more rigid.

[Jayesh Singh]

Hi Steven,

You can definitely place vedge behind the firewall with public IPs on the firewall and nat in place so that vedges take public ip to reach other vedges and controllers.

Just make sure you have all the required firewall ports opened to establish control and data tunnels.

I have been in a similar situation as you and deployed it the same way... That's how it has to be done.

Let me know if that helps and also if you have any specific queries then please shoot...

Regards,

Jayesh

***Rate all posts that are helpful. Mark it as a solution if that answers your query, it might help other users who are having the same query***

[Steven Williams]

Ok so how were you terminating the DIA circuits to your network?

[Jayesh Singh]

Its a brownfield, so link is terminated on existing wan router which is connected to the firewall via outside leg and inside leg is connected to location core switch(trunk). 

We brought vedge inline via L2 link(using the same trunk) from core switch connecting Vedge to the firewall. So on vedges we have the private IP and nat is done on firewall.

Hope that is clear, do u see any challenge in your topology?

Regards,

Jayesh

[Steven Williams]

So in the case where I am bringing in dual DIAs and plan to use both via routing, QoS, etc, etc, how is that going to work? Doesnt the vedge make that choice by probing each DIA for best performance?

[Jayesh Singh]

All those features are part of overlay. Stuffs i mentioned in previous post were part of underlay.

[Steven Williams]

Right but if your vedge is southbound of the firewalls you will not terminate the DIAs into the vedge, you will basically terminate the two DIAs probably into a internet switch pair, then down to the firewalls, then to the vedge. I mean you said vedge is layer 2 so does it just act like a passthrough device at that point?

[Jayesh Singh]

Well.. when i wrote L2 i actually meant core switch to be L2 providing access between vedge and firewall on /30 or /29 subnet.. like point to point. This setup was particular to the environment so that existing devices and new vedges could coexist.

Vedge doesn't require DIAs to be terminated directly on it, rather it just needs the path to form tunnel with other vedges. So even if we have private IPs on our vedges and we do nat on firewall, vedge would establish ipsec tunnel with other vedges till we have internet path through firewall. And firewall essentially would b part of underlay for this sdwan path(ipsec tunnel/overlay).

P.S.: Replying from my mobile device so keeping it short.