IP addressing design question

Answered Question
May 24th, 2010
User Badges:

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

Correct Answer by Kyle Cohne about 6 years 11 months ago


The one thing I have not been able to resolve yet is the NAT issue.  They need to be able to talk to address 172.27.6.133.  For us on the inside this is ip address 192.168.3.2.



Are you saying that when they access 172.27.6.133 that this should resolve to 192.168.3.2? on your end.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.2 (12 ratings)
Loading.
Jon Marshall Mon, 05/24/2010 - 12:09
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Kevin


Could you post the visio as .jpg please ?


Jon

Jon Marshall Mon, 05/24/2010 - 13:51
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Kevin


Is the 3750 switch acting purely as a L2 switch at present ?


Also this is your WAN so i'm unclear why you need to allocate 172.27.6.130 address to the WAN router ?


Jon

Kevin Melton Mon, 05/24/2010 - 14:04
User Badges:

Jon


Here are your answers


Is the 3750 switch acting purely as a L2 switch at present ?


Currently it is configured only as Layer 2.  Right now there are two VLAN's with IP interfaces configured, but I do not think any routing occurs between them.


Also this is your WAN so i'm unclear why you need to allocate 172.27.6.130 address to the WAN router ?


It is due to requirements from the Vendor.  Originally during planning, we had told the vendor that they would need to configure an IP address of 192.168.15.10 on that interface.  This was actually on a planning document that we sent to the vendor some time ago.

Today during turn up, it seems like the vendor must never have read or either it did not register with them, as they are now telling us that they dont NAT, and that we must NAT, and that we have to NAT the 172.27.6.130 address which they have configured on the router.


Thanks


Kevin

Jon Marshall Mon, 05/24/2010 - 14:17
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

k-melton wrote:



Today during turn up, it seems like the vendor must never have read or either it did not register with them, as they are now telling us that they dont NAT, and that we must NAT, and that we have to NAT the 172.27.6.130 address which they have configured on the router.


Thanks


Kevin


Kevin


Yes you could configure another vlan on the 3750 switch for the 172.27.6.x network and turn on routing is the short answer. But i am still confused about the 172.27.6.130 interface.


If this is the WAN interface it shouldn't make any difference to the BP what you configure it as. They don't ever need to route to this address and it is your WAN so you should address it as you want. How you NAT their traffic should be up to you. Is the router although in your WAN still managed by the BP.


Perhaps you could clarify because i'm not understanding the issue.


Jon

Kevin Melton Mon, 05/24/2010 - 16:25
User Badges:

Jon


My humble apologies for the confusion.  I probably could have taken more time to try to explain in greater detail but did not.


Here we go with a better attempt at an explanation that hopefully will clear up any confusion. 


The client is getting ready to exchange data with a Business Partner.  The Business Partner will be exchanging data to and from the clients network.

The BP will be collecting data from a specific server on an inside network off of the ASA's inside interface.  The WAN interface of the ASA is the gateway for the 15.X/23 WAN network.  This ASA WAN interface plugs into the switch in question in this equation, landing on a port in the WAN vlan 15.  As is easy enough to tell from the diagram, others routers are also in this subnet. 


The Business Partner 2 months ago forwarded a questionnaire asking specific network questionnaire which was meant to ascertain all of the important IP addresses and other network requirements.  This in order that they can configure their router at a later time thru a aux port on a POTS line.

The document did publish the fact that they will be using a 28 bit Ethernet network at each site within the IP address range of 172.27.X.X to 172.28.X.X, and that NATing would be our (clients) responsibility.  They had also indicated that if the equipment that was going to be monitored were on different LAN’s than the Ethernet connection of their router, a route to these networks must be supplied to their router.


The document then went on to ask for some specific information such as 1) a network address and mask, and then 2) an IP address to assign to their router.  It continued by also asking if a Firewall was going to be in between their router and the Inside network devices, and if so would it be providing NAT, and of course we answered 'yes'.


So based on all that, and considering the diagram, we then decided that the place for that router would be in the WAN network with the Firewall in between it and us.  We assigned the network address 192.168.15.10 for them in that network and sent back the document.  We have had several discussions with them about the configuration, and they never once indicated that they saw a problem with having the 15.10 address on that Ethernet interface.  Today it became an issue, and they reminded us that it was our responsibility to provide NATing.  I had just naturally assumed that since they would have looked at the document when we returned it, that if in fact they could not configure their Ethernet interface to the specified address, that they would have flagged that and let us know.


So we have to have that 172.27.6.130 instead.  And since we dont have a 172.27.6.X network, and also since we had planned on it going into the 15 network, we have to come up with a way to communicate with them.


Currently it seems to me that the best answer is that we turn a switch port to an L3 port and configure 172.27.6.X on it, and then they can put routes on their router for the stuff they need on our inside net.


I hope that cleared things up a bit.  I look forward to your comments.


Kevin

Kevin Melton Tue, 05/25/2010 - 05:42
User Badges:

Jon


Yes the router is managed by the BP.


Is there a way if we use a switchport on the switch as a routed port in the 172.27.6. network, that we could then NAT at the switch?


thanks

Kevin

Jon Marshall Tue, 05/25/2010 - 08:32
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

k-melton wrote:


Jon


Yes the router is managed by the BP.


Is there a way if we use a switchport on the switch as a routed port in the 172.27.6. network, that we could then NAT at the switch?


thanks

Kevin


Kevin


Unfortunately not because the only switch which supports NAT is the 6500.


I'm really sorry but i still cannot understand what the issue is with using a 192.168.15.x address. It should make absolutely no difference to the BP at all. I'm assuming from your diagram that the BP clients are behind the new router ?


What matters to them is -


1) the subnet they use on the LAN side of the router

2) any Natting for the devices behind the ASA which is indeed your clients responsibility but that is taken care of


the interface address of the interface connecting to your WAN is never used by them for anything ie. they don't route to it, their clients don't use it as a default-gateway, and if they want to monitor the router the LAN interface would be the logical one to use.


When you ask about natting on the switch what exactly are you wanting to nat ?


If you have to a 172.27.x.x address on the BP router and i still can't see why then your 3750 has to route. You can either use a routed port as suggested above or a L3 SVI. Whether you want the 3750 to route is another matter. It could confuse things but i don't know enough about the setup to say for sure.


Jon

Kevin Melton Tue, 05/25/2010 - 10:32
User Badges:

Here is what I have been able to accomplish so far John.


We changed the port on the switch to an L3 port, and assigned address 172.27.6.136 to it.  The LAN side over here is network 172.27.6.128/28.  Also remember that they have 172.27.6.130 configured on the Ethernet of their router.


From our switch we were able to ping the Enet on their router at 172.27.6.130.


Here is a table which shows what they need on the LAN side (our side).


Ref

Device Description

IP Address

2

Firewall (if applicable)

172.27.6.132

3

Primary Server,

172.27.6.133

4

Secondary Server

172.27.6.134

5

Tertiary Server

172.27.6.135

Other Devices

172.27.6.136/.142

Other Devices

Other Devices

Other Devices


Here is a table they provided to us that shows what devices on ThEIR side that we will be talking to:



Ref

bus. Partner Server

Primary IP Address

6

BP Test Server 1 & 3

206.223.104.20 & .21

7

BP Test Server 2 & 4

206.223.104.22 & .23

8

BP  EMS  UCS Pair

206.223.104.11

9

BP  EMS  UCS Pair

206.223.104.13

10

Alternate  EMS UCS Pair

206.223.104.15

11

Alternate  EMS UCS Pair

206.223.104.17

12

BUCC EMS

206.223.104.80

13

BP  Primary GMS Server

206.223.105.2

14

BP Secondary GMS Server

206.223.105.3

15

Additional PJM Device(s)



I turned on IP routing on the switch.

I created an interface in our WAN vlan 15 and gave it an ip address of 192.168.15.2.  This is to allow them to get to our ASA at 192.168.15.1.

I also had to create routes to their 206 networks on our switch.  Once that was done then they were able to ping from their host at 206.223.104.11 to the 172.27.6.136 address on our switch.


The one thing I have not been able to resolve yet is the NAT issue.  They need to be able to talk to address 172.27.6.133.  For us on the inside this is ip address 192.168.3.2.  I tried putting the following into place but it did not work:


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?


Thanks Jon


Kevin

Correct Answer
Kyle Cohne Tue, 05/25/2010 - 10:43
User Badges:


The one thing I have not been able to resolve yet is the NAT issue.  They need to be able to talk to address 172.27.6.133.  For us on the inside this is ip address 192.168.3.2.



Are you saying that when they access 172.27.6.133 that this should resolve to 192.168.3.2? on your end.

Kyle Cohne Tue, 05/25/2010 - 11:00
User Badges:

Then I would suggest using a static nat statement like this.


"ip nat inside source static 192.168.3.2 172.27.6.133"


Then when somebody tries to access the 172 address it will resolve to the 192.


Hope this Helps.

Jon Marshall Tue, 05/25/2010 - 11:06
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Kyle


I don't think Kevin can do that because he already has a static ie.


static (inside,outside) 192.168.3.0 192.168.3.0 netmask 255.255.255.0


so therefore you need to use policy nat.


Jon

Kevin Melton Tue, 05/25/2010 - 11:08
User Badges:

Kyle


The only issue I see with your statement is that it looks like a statement for an IOS router.  We are performing the NAT on an ASA.


thanks


Kevin

Jon Marshall Tue, 05/25/2010 - 11:10
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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 Tue, 05/25/2010 - 11:04
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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 Tue, 05/25/2010 - 11:48
User Badges:

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 Tue, 05/25/2010 - 12:27
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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 Tue, 05/25/2010 - 13:02
User Badges:

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 Tue, 05/25/2010 - 13:20
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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 Tue, 05/25/2010 - 13:38
User Badges:

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 Tue, 05/25/2010 - 13:48
User Badges:

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 Tue, 05/25/2010 - 14:03
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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 Tue, 05/25/2010 - 14:27
User Badges:

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 Wed, 05/26/2010 - 04:10
User Badges:

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 Wed, 05/26/2010 - 04:16
User Badges:

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 Wed, 05/26/2010 - 07:48
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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 Thu, 06/03/2010 - 08:43
User Badges:

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 Wed, 05/26/2010 - 07:56
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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

Kevin Melton Wed, 05/26/2010 - 08:10
User Badges:

Jon


I am really impressed with what you have had to do at Network Rail in the past.  Yes sometimes this stuff which seems like you would be able to get it to work without much issue can be inherently problematic.


One of your last recommendations was to place the more specific NAT in the configuration on the ASA prior to the more general one.  This has worked so far.  I did not get the error message indicating conflict like in the past.


I am still waiting on the BP at this point.  The BP router is actually (found out yesterday) managed by Verizon, so even the BP does not have any more than Privilged mode on the box, and no PRIV EXEC.  So the BP has to contact Verizon any time they want to make a change.  I am hoping that they can now add he route for the 172.16.7.0/24 network, and in light of the fact that I added the route on the switch to ship traffic to the ASA, and then also placed the route on the ASA to ship traffic for the 172.16.7.0/24 to the switch interface @ 192.168.15.2, we may finally have success.


I will let you know.  Thanks again for sharing all of your insight from past experience.  This has gotten messy.  The only thing management cares about is "get it working".  You know the drill.


I will keep you posted.


Kevin

Actions

This Discussion