Tricky NAT and VPN

So we have a client that we are looking to do some inbound telemarketing for and everything seems to be going good. Everyone on our team is getting along with everyone on the client’s team and we all understand what needs done.

The first thing that needs completed is a L2L VPN between our ASA and the client’s PIX. Here are the requirements:

1) Private IPs are not allowed to traverse the VPN
2) Need a PAT for users connecting to the clients Terminal Server (initiated from users)
3) Need a Static NAT for connections between AES of Avaya and client’s Verint server (connection is bidirectional, so can be initiated by either side)
4) Need a Static NAT for connections between CLAN of Avaya and client’s Verint system (connection is bidirectional, so can initiated by either side)

Giving these requirements I used the ‘nat’ with an ACL and ‘global’ commands to create a policy NAT for any systems using RDP (tcp/3389) to the client’s TS.

I then used ‘static (inside,external) x.x.x.178 x.x.x.8 ‘ for bidirectional connections between the AES and Verint

Next I used ‘static (inside,external) x.x.x.180 x.x.x.14’ for bidirectional connections between CLAN and Verint

Now we tested the RDP connection and they work beautifully.

Next the Verint to the AES is working fantastic as well.

But this is the tricky part:

From as far as I can tell, the Verint system tells the AES to use the CLAN to record the calls; the CLAN then connects to the Verint system to push live call recording.

Again, AFAIK, the Verint server has one spot to input where you are expecting to get the recordings from and who to use to initiate the the recordings; the Verint system then sends this IP to the AES telling the AES to use .180 as the CLAN to connect to. However, given that the AES and CLAN are on the same network and .180 is only live when .14 goes out the ‘external’ of the ASA, the AES cannot reach .180

I know that packets to .180 have to hit the ASA, so I made two changes:

‘static (inside,inside) .180 .14’
NAT (inside) 0 ACL
updated ‘ACL’ to include any traffic to .14

Now from an internal machine I can ping .180 and get replies from .14, so I know the translation is working.

From the AES, however, it still fails. Even having Verint tell the AES to use .180 it still fails, but it does translate over the ASA.

We had the client replace the one instance of .180 with .14 to see if it would tell the AES to use .14, but no luck. Traffic did not even reach the AES.

So it would seem to be a limitation of the Verint that it cannot except recordings from one IP while telling Avaya to use another.

Given that .180 only came to be using the VPN, I came up with the following solution:

Update the VPN to use the real IP of the CLAN instead of the NAT’d IP. The network team at the client believes this would work, however, it is against their security policy for the following reasons:

1) NAT’ing adds a layer of protection and security

2) Using RFC1918 on a VPN may cause issues with their current IP scheme

My thoughts are:

1) security through obscurity is not security

2) a very reasonable issue that can be combated with either a host route or route maps

Last I heard, they want me to place another device in front of the AES and CLAN to fix the issue. Now saying that, the only thing I can think of is to put a router between the two that NATs .180 to .14 and .14 to .180. But I am unsure if that would work.

So now I ask you networkers of the Internet, what would you do in this situation?

EDIT: just had an ‘a ha’ moment. I used NAT 0 so that traffic to .14 isn’t NAT’d when going from inside to inside. What if I update this to use the IP of the ASA’s inside interface? The return traffic would then need to hit the firewall and therefore should be NAT’d back to .180! Ima give it a shot!

EDIT: So to NAT to to the inside int I had to remove the added entry to the ACL in the ‘nat (inside) 0’ from above and add ‘global (inside) interface’. Nonetheless, now when I ping .180 from inside I get replies from .180. A bit exciting as I’ve been beating myself over the head the last few days on this one. Have to wait ’til the morn’ to have the client test.

About Richard Svensson

Richard is the Sr Network Administrator at an international automotive interiors manufacturer. View all posts by Richard Svensson

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: