IP addressing design question

[Kevin Melton]

Forum

I have a rather interesting design dilema at a client site.  The client is preparing to install a router betweent themselves and a business partner for some data exchange.  While discussing this with my collegues, we determined the best place to put the Business Partner router was in our WAN network.  Our WAN network operates in address space 192.168.15.0/24.  We currently have three other routers in that WAN network (one for MPLS, one for Frame, and one for the backup ISDN.  The addresses are 15.50 (MPLS rtr), 15.4 (Frame) and 15.5 (ISDN).

This WAN network has a gateway to get to the clients INside networks at the client ASA (WAN interface IP 192.168.15.1).  During planning sessions with the Business Partner a month ago, we told them that we were assigning them the IP address 192.168.15.10 and placing them into the WAN network.  We were then going to NAT the devices on the Inside networks that need to talk to the BP and add the appropriate ACL entries to the ACL which we already have in place inbound on the WAN interface on the ASA.

During turn up activities with the business partner today, we found out that they cannot use the 192.168.15.10 address because there company policy mandates that they use IP address scheme 172.27.X.X.

There is a 3750 switch in between the routers and the ASA.  We have a VLAN created on the switch for the WAN network.

I am not sure how to get the IP address 172.27.6.130 on the BP router to route to the 192.168.15.1 interface on the ASA.

If need be I guess we could always create another VLAN on the switch and give it a 172.27.X.X address.  Then the switch would have to route to the 15.0 WAN network.

DIAGRAM IS  ATTACHED

I am open for any suggestions here.

Thanks

Kevin

[Jon Marshall]

Kevin

You are correct that it is an IOS statement but even translated to an ASA it won't work without policy NAT as far as i know.

Jon

[Jon Marshall]

Kevin

static (inside,WAN) 192.168.3.2 172.27.6.133 netmask 255.255.255.255  - i was actually getting a message that this was overlapping with an existing static map: static (inside,WAN) 192.168.3.0 192.168.3.0 netmask 255.255.255.0

So then I tried the following configuration:

1.  access-list policy_PJM permit ip host 192.168.3.2 host 206.223.104.11
2.  nat (inside) 2 access-list policy_PJM
3.  global (WAN) 2 172.27.6.136

this because they have a ping nailed up from their server at 206.223.104.11 to the address 172.27.6.133 (which is our 192.168.3.2). They were leaving this ping nailed up and were going to call me once they were receiving replies.

Perhaps you can tell me what I am doing incorrectly with the NAT?

try this instead

access-list PNAT permit ip host 192.168.3.2 host 206.223.104.11

static (inside,outside) 172.27.6.133 access-list PNAT

Edit - by the way for future reference with an ASA it is the other way round with NAT statements ie.

static (inside,WAN) 192.168.3.2 172.27.6.133 netmask 255.255.255.255

should actually be

static (inside,WAN) 172.27.6.133 192.168.3.2 netmask 255.255.255.255

it is not like IOS.

Jon

[Kevin Melton]

Jon I tried using

access-list PNAT permit ip host 192.168.3.2 host 206.223.104.11

static (inside,outside) 172.27.6.133 access-list PNAT

but with no success.  They are still not seeing responses from 172.27.6.133 from the origin address of 206.223.104.11.

I did have a question about the ACL however

IF they are pinging from 206.223.104.11, shouldnt the ACL read

access-list PNAT permit ip host 206.223.104.11 host 192.168.3.2

??

thx

[Jon Marshall]

k-melton wrote:
Jon I tried using
I did have a question about the ACL however
IF they are pinging from 206.223.104.11, shouldnt the ACL read
access-list PNAT permit ip host 206.223.104.11 host 192.168.3.2
??
thx

Kevin

static NAT is bi-directional so the acl works both ways ie. from inside or outside.

When they try to connect what is the xlate table showing ie. do you get a translation for the above ?

How are they trying to connect and do you see hits on your acl on the outside interface of the firewall ?

Jon

[Kevin Melton]

Jon

they have simply had a ping nailed up that originates from 206.223.104.11 to 172.27.6.133 (our 192.168.3.2).  I have ran debug icmp trace on the ASA but do not see any ICMP traffic originating from 206.223.104.x.

When they try to connect what is the xlate table showing ie. do you get a translation for the above ?

ODEC-ASA(config)# sho xlate
834 in use, 2562 most used

Global 192.168.3.0 Local 192.168.3.0
Global 192.168.4.0 Local 192.168.4.0
Global 192.168.2.3 Local 192.168.2.3
Global 192.168.1.0 Local 192.168.1.0
Global 192.168.7.0 Local 192.168.7.0
Global 192.168.60.0 Local 192.168.60.0
Global 192.168.176.0 Local 192.168.176.0
Global 172.27.6.133 Local 192.168.3.2

How are they trying to connect and do you see hits on your acl on the outside interface of the firewall ?

Currently Jon they are just pinging the address 172.27.6.133.  Nothing else is trying to connect because we are simply in turn up phase right now.

I think that the ACL we are referencing is a WAN ACL and not the Outside ACL.  Anyhow I just enabled icmp echo any any on the ACL inbound on the WAN interface.  Perhaps that was the issue where they could not ping in.

the guy at the BP site has now left for the day.  I am supposed to get back on the horn with him at 0700 EST. 

I hope by adding in the ACL entry that may fix this.

Talk to you soon Jon.

Kevin

[Jon Marshall]

Kevin

Sorry i have finally caught up with you

The missing piece of info i didn't get was that you are natting 192.168.3.2 to 192.168.3.2 for the other clients.

Okay what you have won't work. It can't because when the packet gets to BP router destined for your client the BP router arps out for 172.16.6.133. Now if the ASA had an interface in that network it could answer but it doesn't and you are routing via the 3750. So the packet will never get to the ASA.

The solution is -

1) you need a separate network agreed between you and the BP to use for presenting your internal servers that they want to access. For arguments sake lets say you agree on 172.16.7.0/24.

2) on the BP router you need to add a route -

  ip route 172.16.7.0 255.255.255.0 <3750 172.16.6.x address that connects to BP router>

3) then on ASA setup your static policy NAT as before but use a 172.16.7.x address.

The above requires that the BP then connect to the 172.16.7.x address which will get translated to 192.168.3.2 when it gets to your ASA.

If the BP insists that you use an address from the subnet allocated to the outside interface of the BP router ie. 172.16.3.x then you can't make it work unless you have a spare interface to use on your ASA and even then it will be messy.

Jon

[Kevin Melton]

Jon

That makes sense as I do not see any of the echo requests ever hitting the

ASA,  and the BP had sent me an ARP table list from his router that showed :

User Access Verification (Domain 3)

TACACS Username:

TACACS Password:

pjmint->sh arp      at 13:39:56

Protocol  Address      Age (min)  Hardware Addr   Type   Interface

Internet  172.27.6.130            -   04fe.7f37.27e0  ARPA   FastEthernet0/0

Internet  172.27.6.133            0   Incomplete      ARPA

Internet  172.27.6.136          201   001a.e266.f6c3  ARPA   FastEthernet0/0

So here are my latest questions based on your last reply:

The solution is -

1) you need a separate network agreed between you and the BP to use for presenting your internal servers that they want to access. For arguments sake
lets say you agree on 172.16.7.0/24.

2) on the BP router you need to add a route -
  ip route 172.16.7.0 255.255.255.0 <3750 172.16.6.x address that connects to BP router> 

3) then on ASA setup your static policy NAT as before but use a 172.16.7.x address. 

Jon do you mean to then NAT 172.27.7.X to the Real inside address of 192.168.3.2???  Would the statement look like

static (inside,WAN) 192.168.3.2 172.27.7.X netmask 255.255.255.255?

The above requires that the BP then connect to the 172.16.7.x address which will get translated to 192.168.3.2 when it gets to your ASA.

If the BP insists that you use an address from the subnet allocated to the outside interface of the BP router ie. 172.16.3.x then you can't make it work
unless you have a spare interface to use on your ASA and even then it will be messy.

We do not have a spare interface on the ASA so this wont be any option, thank goodness!

Thanks

Kevin

[Kevin Melton]

Jon

I re-read the provided solution and am unclear.  Our ASA does not have an interface in the 172.16.7.0 network that you are referencing either, so I do not understand why this is any different than using the 172.27.6.0 network.

thanks

Kevin

[Jon Marshall]

k-melton wrote:
Jon
I re-read the provided solution and am unclear.  Our ASA does not have an interface in the 172.16.7.0 network that you are referencing either, so I do not understand why this is any different than using the 172.27.6.0 network.
thanks
Kevin

Kevin

The issue is that because the IP address 172.16.3.133 is on the same subnet as the BP router interface ie. 172.16.3.130 it cannot be routed to the ASA because arp is only local to the subnet and the BP router arps out for 172.16.3.133 because it knows the address is local to it's outside interface.

What you need is a subnet that is not local to the BP router interface so that you can route it to the ASA ie. if you used 172.16.7.0/24 then this is not local to the BP router so it has to send packets destined to the 172.16.7.x network to the 3750. I forgot to mention that you would also need a route on the 3750 pointing the 172.16.7.0/24 to the outside interface of your ASA.

So on the BP router -

ip route 172.16.7.0 255.255.255.0 <3750 IP address in 172.16.3.x network>

on 3750

ip route 172.16.7.0 255.255.255.0 192.168.15.1

so the 3750 then routes 172.16.7.x traffic to the ASA. Once the traffic gets to the ASA because of your static NAT statement the ASA in effect takes "responsibility" for the 172.16.7.x address you have used to NAT to 192.168.3.2. That is what proxy-arp on the ASA is all about.

Note the ASA would also need a route back to the 3750 192.168.15.x address for the 172.16.7.0/24 network so that the 3750 can then forward it back to the BP router.

As for the NAT statement you still need to use policy NAT so -

static (inside,WAN) 192.168.3.2 172.27.7.X netmask 255.255.255.255?

would not be right. 2 things wrong -

1) as mentioned before with the ASA the global address goes before the local address so the statement would be -

static (inside,WAN) 172.27.7.X 192.168.3.2 netmask 255.255.255.255

but that wouldn't work anyway because you are already natting 192.168.3.0 to 192.168.3.0 from the inside to outside.

2) so you need policy nat statement as before ie.

access-list PNAT permit ip host 192.168.3.2 host 206.223.104.11

static (inside,outside) 172.27.7.x access-list PNAT

Jon

[Kevin Melton]

Jon

We will see if in fact the BP is willing to talk to an alternate agreed upon network.  They have been somewhat inflexible to this point in that they definetely want for to talk to only that 172.27.6.128/28 network on our side of their router.  But I will ask them anyway and try to explain the difficulty.

Thanks for all of your thourough explanations.  Most of what you are explaining i have learned and forgotten...Of course, proxy-arp on the ASA!  You know the guy from the BP had sent me over the ARP table from their router and that should have been clue enough.

I will be working with the BP at 0700 tomorrow and will let you know how it goes.

Thanks

Kevin

[Kevin Melton]

Jon

in your last part of your email, you indicated we should use policy NAT again using:

access-list PNAT permit ip host 192.168.3.2 host 206.223.104.11

static (inside,outside) 172.27.7.x access-list PNAT

did you not mean:

static (inside, WAN) 172.16.7.0 access-list PNAT?

I just wanted to verify this prior to configuring it...

Thx

Kevin

[Kevin Melton]

Jon

I actually ran into an issue trying to configure the following statement

ODEC-ASA(config)# no static (inside,WAN) 172.27.6.133  access-list PNAT
ODEC-ASA(config)# static (inside,WAN) 172.16.7.133 access-list PNAT
WARNING: real-address conflict with existing static
  inside:192.168.3.0 to WAN:192.168.3.0 netmask 255.255.255.0
ODEC-ASA(config)#

Thanks

Kevin

[Jon Marshall]

k-melton wrote:
Jon
I actually ran into an issue trying to configure the following statement
ODEC-ASA(config)# no static (inside,WAN) 172.27.6.133  access-list PNAT
ODEC-ASA(config)# static (inside,WAN) 172.16.7.133 access-list PNAT
WARNING: real-address conflict with existing static
  inside:192.168.3.0 to WAN:192.168.3.0 netmask 255.255.255.0
ODEC-ASA(config)#
Thanks
Kevin

Kevin

There could be a couple of issues here but unfotunately i don't have an ASA handy to test with -

1) you may need to enter the more specific NAT ie. the policy NAT before you enter the more general one

2) alternatively you may need to policy NAT the other entry as well ie. for all the other users that access 192.168.3.2 on it's real IP address you may need a policy NAT statement.

I notice you are still using 172.27.6.133 - this won't work as discussed yesterday.

One final thought occured if you cannot get this to work but it does rely on your BP doing something on their router. You could do the NAT on their router ie.

WAN interface with the 172.27.6.130 address = fa0/1

LAN interface = fa0/0

int fa0/0

ip nat outside

int fa0/1

ip nat inside

ip nat inside source static 192.168.3.2 172.27.6.133

then you would need to add routes for 192.168.3.0/24 network pointing to the 3750. This solution assumes that your BP is not doing any natting already because if they are they will probably have assigned "ip nat outside" to the WAN interface and you need them the other way round.

Jon

[Kevin Melton]

Jon

I wanted to talk to you about the following statement:

2) alternatively you may need to policy NAT the other entry as well ie. for all the other users that access 192.168.3.2 on it's real IP address you may need a policy NAT statement.

One week later, we konw that we would have to policy NAT the other entry.  I had placed the policy NAT that we had written last week for the more specific translation (192.168.3.2 getting translated to 172.27.6.133) and had placed it above the more general one.  This ended up causing problems on the main systems that rely on the "static (inside,WAN) 192.168.3.0 192.168.3.0 netmask 255.255.255.0" , and we ended up having to put the more general statement "above" the more specific statement.

So what I need is exactly what you have referenced in your number 2 earlier.  I need for 192.168.3.2 to get translated to 172.27.6.133 IF and only IF the source address is coming from the BP address 206.223.104.11.  I need for ALL OTHER address to translate 192.168.3.0 network to itself to the WAN interface.

How can I write this policy?

Thanks Jon

[Jon Marshall]

Kevin

As you can see from my last reply things are getting quite messy. When i was working at Network Rail i had to connect up over 100 other companies via VPN to our network and there were times when we had to be a little inventive as to how they were connected up due to addressing, device capability at their end etc.

We wanted them to use our application so the remit was we must connect them no matter what. We did but it was not an elegant solution and was a nightmare to manage. If at all possible you would be better to go back and explain the issues and see if they can route to 192.168.3.2 or at least do the NAT on their router.

I appreciate it's not always that easy but so far we have had to -

1) turn on ip routing on the 3750 switch which is not ideal

2) add policy NAT to the firewall which may or may not work at the moment

3) configure additional ip routes to get the BP traffic to the ASA

we may then need to policy NAT your existing static which works for everyone else.

Jon