Asymmetric problem

[Jon Marshall]

Hi all

I am trying to answer a question in WAN Routing and Switching and have hit a problem with using 2 inside interfaces on an ASA.  Basically there is an ASA that is going to need 2 inside interfaces. The main inside interface inside_1 is used for internet and so has return routes for the LAN subnets. There is a requirement for a new inside interface inside_2 for a VPN to a remote site.

So my question is, if traffic from the LAN goes into inside_2 and then across the VPN to a remote site but the return traffic when it comes back is routed out the inside_1 interface does the ASA see this as asymmetric traffic. It sees the whole connection but does it keep track of the interfaces used in the state table as well.

You can see the thread here -

https://supportforums.cisco.com/thread/2257082?tstart=0

Thanks for any help.

Jon

[Jouni Forss]

Hi Jon,

Only had a quick glance on the discussion. Not sure I understood it correctly though

Was the original problem that the central site router before the ASA was forwarind the traffic to the MPLS network rather than to the ASA when it comes to traffic destined to Site 50?

The poster didnt mention anything about this but wouldnt NAT be an option here (at remote site before encryption)? Do a Static NAT for the Site 50 network 1:1 to an equal size NAT network? Naturally if there is something in place that relies on reaching the hosts with their actual IP addresses it might get a little tricky or just mean a lot of extra work.

Your original question I can't really answer without testing it myself and that is not possible at the moment simply because its around 11.58pm here in Finland.

I would think it would be impossible for a single connection to use 3 different interfaces on the ASA. Then again I would presume that if the ASA forms the connection from "inside_2" to "outside" that the return traffic would use the "inside_2" for forwarding the return traffic also. Again, I would have to test this. But I would probably avoid creating any extra complexity to the network if at all possible.

All in all it seems to me that it would be a lot simpler to implement a 1:1 Static NAT for the migrating site which would essentially avoid any problems for the routing but possibly cause other problems.

- Jouni

[Jon Marshall]

Hi Jouni

Was the original problem that the central site router before the ASA was forwarind the traffic to the MPLS network rather than to the ASA when it comes to traffic destined to Site 50?

Yes, all traffic goes via MPLS and the router is owned by AT&T so it cannot be configured with routes etc.

The poster didnt mention anything about this but wouldnt NAT be an option here (at remote site before encryption)? Do a Static NAT for the Site 50 network 1:1 to an equal size NAT network?

Do you mean use a subnet that is not routed via MPLS so the AT&T router simply forwards it on to the ASA. Yes this could work assuming the AT&T router sends all unknown traffic to the ASA ie. i wouldn't want to use public addressing, just an unused private IP address range and hope it gets routed to the ASA at the main site. This is assuming they are not doing any private address range filtering on the AT&T router.

All in all it seems to me that it would be a lot simpler to implement a 1:1 Static NAT for the migrating site which would essentially avoid any problems for the routing but possibly cause other problems.

It would have to be policy NAT as they still need to access the internet. I have done a lot of firewalling in the past but not a lot on ASAs with 8.x code onwards. And if it's 8.3 NAT onwards i'm still getting up to speed on that. So i may come back to this post if he decides to go that route.

I'd be interested, if/when you get time to see if it does actually get routed back out of the new interface on the way back.

Thanks

Jon

[Jouni Forss]

Hi,

Will see if I could test this tomorrow maybe.

I don't have that many devices at home but I imagine I can improvise with the ones I have to simulate the situation.

Yeah, you are correct it would be a Static Policy NAT.

The correct format in the new software would be

object network CENTRAL-SITE

subnet

object network LOCAL-SITE

subnet

object network LOCAL-SITE-MAPPED

subnet

nat (inside,outside) source static LOCAL-SITE LOCAL-SITE-MAPPED destination static CENTRAL-SITE CENTRAL-SITE

It would essentially mean that LOCAL-SITE would be NATed to the LOCAL-SITE-MAPPED when the destination (or source depending on the direction) was CENTRAL-SITE

A bit off topic but if you want to have a look, I made a NAT 8.3+ document on the CSC. Its still work in progress and I want to add a lot of more information to it and different NAT examples. The current example NAT configuration section itself is pretty vague at the moment, only containing pictures with the configurations. I will probably also rewrite some of the sections also.

Will have to look when I get time for that. I am on vacation now so will have to see if I have the energy after christmas is over.

Heres a link to the document

https://supportforums.cisco.com/docs/DOC-31116

I am still wondering how the MPLS network routing has been handled.

Something tells me its static routing combined with dynamic routing if the Site 50 network truly keeps adverticing after disconnecting the Site 50 Router? I mean the ISP must have a static route in place that keeps adverticing this Site 50 network even when its not live instead of running something like BGP between the ISP and the Customer to determine if the network is there or not. Then again I am not sure if the customer has tried to disconnect the whole Site 50 from the MPLS network and see if there is any effect on the situation?

- Jouni

[Jon Marshall]

Jouni

I am still wondering how the MPLS network routing has been handled.

I am actually trying to find this out now. They haven't disconnected it yet.

If they are using a dynamic routing protocol to exchange routes then once the MPLS router is disconnected at the remote site then you don't need any config because the AT&T router at HQ would just pass the traffic to the ASA because it is know an unknown destination. And the return traffic would come back via the internet and be routed back out the same interface.

It really comes down to whether the OP in the other thread can find this out because he can't log on to the HQ AT&T router and if they are using a routing protocol.

If they are then any config we do is only so that they can test the tunnel while the MPLS network is stilll connected at the remote site. So it's a lot of work for a very short term solution.

I have given him the options but because he might want to test with the MPLS connection still live the source IPs from HQ would need to have NAT as well. He does have a spare router at HQ so another option would be -

core switch -> new router -> (new inside interface) ASA -> internet

the switch is 3750 so doesn't support NAT. But the new router could NAT the source IPs  and send them to the temporary new interface on the ASA, bypassing the AT&T router. Traffic in site 50 could route the NAT subnet back to their ASA and then add a route on the HQ ASA for the NAT subnet via the new inside interface. 

It all depends on what he wants to do but i just want to give him options and do what is easiest because as i say it could just be while he tests.

I will definitely have a look at that doc, could be very useful.

Edit - forgot to say, have a good vacation and please don't feel the need to spend too much time on this as at least we have some options available to us.

Jon

[Collin Clark]

I saw your response post John and like Jouni stated I think there is some routing that is handled by the ISP. I've seen some ISP's peer an IGP in one data center but not another or different IGP protocols! Anyway, yes he could add an interface to the DMZ ASA and connect it to the NJ Core. No special NAT needed other than the NAT for VPN. This is of course assuming he takes out the router at the 50 Branch or makes the Branch 50 ASA the default gateway. To answer your question directly, yes it keeps track of the flow as well as the interfaces the flow traverses. It will not see the flow as asymmetric because the firewall understands that the "first" flow was VPN. I've done a couple of deployments where the tunnel terminates on the ASA (tunnel all) and then have it NAT right back out the outside interface for filtered Internet access.

[Jon Marshall]

Hi Collin (notice i can spell your name correctly )

Just to clarify, are you saying that a VPN tunnel can go through inside_2 interface and out to the internet then back in and be routed out the inside_1 interface and it will work ? 

I think that's what you are saying, just want to be sure.

Jon

[Collin Clark]

It sure will. The only gotcha is your NAT, Site 50 will NAT from the outside to the outside! The ASA thinks Site 50 is outside because it's on the other end of a VPN tunnel. Depending on the routing and how he puts it in, he may have to disable RPF, but looking at this scenario I don't he'll have to.

*You're only 1 of 3 that spells my name correctly! I hsould change my username to Dude or dood

[Jon Marshall]

It sure will. The only gotcha is your NAT, Site 50 will NAT from the outside to the outside! The ASA thinks Site 50 is outside because it's on the other end of a VPN tunnel. Depending on the routing and how he puts it in, he may have to disable RPF, but looking at this scenario I don't he'll have to.

I really need to get up to speed on the ASAs because i don't understand any of the above. Not your fault, due to my lack of understanding i think.

Assuming the MPLS router is still advertising site 50 routes, if we NAT the source IPs from HQ doesn't that solve all the problems at site 50 apart from a route needed at site 50 for the NAT subnet from HQ going via site 50 ASA ie. no NAT needed at remote site. It would mean having another interface on the HQ ASA and using the router though so if you are suggesting an easier solution then please just explain it to me like you would a complete novice.

Which to be honest i think i might well be now. I never really got over the change from pix to ASA, a bit like the change from CatOS to IOS on switches took ages to get used to.

We don't like change us older people

Jon

[Collin Clark]

BTW- I only have two bookmarks in CSC and Jouni's NAT doc above is one of them. Very well written and the only doc you need to learn the new NAT.