NAT Issue between Two Networks

Unanswered Question
Jul 14th, 2008

I have a 3meg multilink connection going directly to the internet to a service providers network, then a Frame T1 that is coming back into my private network (this private network does have access to internet via different service provider). We want all internet traffic to NAT out to the multilink connection. However, we have servers that are on the private network that need to be accessed through the FR T1 on the private network. These servers will be accessed from the outside world, come through the private network and come accross the Frame T1 on the router. The below config is the closest we have got it to work. But the servers cannot be accessed via the Internet from outside the private network. Nor will any NAT translations occur out the multilink. I think this is a crappy design, but its what we are currently stuck working with. We denied the individual servers in the NAT config with an extended ACL Thoughts? Clear as mud ain't it :-)

interface Multilink1

ip address 12.89.x.x 255.255.255.252

ip nat outside

ip virtual-reassembly

ip route-cache flow

no cdp enable

ppp multilink

ppp multilink fragment disable

ppp multilink group 1

!

interface FastEthernet0/0

ip address 12.x.x.x 255.255.255.240 secondary

ip address 150.x.x.x 255.255.255.0

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat inside

ip virtual-reassembly

ip route-cache flow

duplex auto

speed auto

no mop enabled

!

interface FastEthernet0/1

description $ETH-LAN$

ip address 10.0.0.1 255.0.0.0

ip access-group 103 out

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat inside

ip virtual-reassembly

ip route-cache flow

duplex full

speed 100

no cdp enable

no mop enabled

!

interface Serial0/0/0:0

ip address 172.16.203.246 255.255.255.252

ip nat outside

ip virtual-reassembly

encapsulation frame-relay IETF

ip route-cache flow

!

interface Serial0/1/0:1

description Serial for 3mb connect

no ip address

encapsulation ppp

ppp multilink

ppp multilink group 1

!

interface Serial0/1/1:1

description Serial for 3mb connect

no ip address

encapsulation ppp

ppp multilink

ppp multilink group 1

!

ip classless

ip route 0.0.0.0 0.0.0.0 172.16.203.245

ip route 66.x.0.0 255.255.0.0 172.16.203.245

ip route 150.x.0.0 255.255.0.0 172.16.203.245

ip route 165.x.0.0 255.255.0.0 172.16.203.245

ip route 170.x.0.0 255.255.0.0 172.16.203.245

ip route 170.x.0.0 255.255.0.0 172.16.203.245

ip nat pool ATT 12.52.x.x 12.52.x.x netmask 255.255.255.240

ip nat inside source list NAT_ACL pool add_pool overload

!

ip access-list extended NAT_ACL

deny ip host 150.x.x.x any

deny ip host 150.x.x.x any

deny ip host 150.x.x.x any

deny ip host 150.x.x.x any

deny ip host 150.x.x.x any

deny ip host 150.x.x.x any

deny ip host 150.x.x.x any

deny ip host 150.x.x.x any

deny ip host 150.x.x.x any

deny ip host 150.x.x.x any

deny ip host 150.x.x.x any

deny ip 150.208.x.0 0.0.0.255 150.x.0.0 0.0.255.255

deny ip 150.208.x.0 0.0.0.255 170.x.0.0 0.0.255.255

deny ip 150.208.x.0 0.0.0.255 66.x.0.0 0.0.255.255

deny ip 150.208.x.0 0.0.0.255 170.x.0.0 0.0.255.255

permit ip 150.208.x.x 0.0.0.255 any

permit ip 10.0.0.0 0.255.255.255 any

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Paolo Bevilacqua Mon, 07/14/2008 - 14:17

It is not a crappy design.

Configure:

ip nat inside source static udp I.I.I.I 80 P.P.P.P 80

I and P are respectively the internal and public addresses for the server. Ideally, P should not be in any pool, but even if it is, nothing bad should happen.

Unrelated to that you should configure routing to eliminate the ugly static routes, and in a future, easly obtain backup for the T1. That is done via VPN/GRE tunnels these days.

Please rate post if it helps!

kenneth.rogers Mon, 07/14/2008 - 14:45

paolo.....thank you for the reply.....In this case the public IP will not have an internal address for it. They (the 150.x.x.x range) will not be NAT and will need to be accessed from the outside world, thru our internal network annd accross the frame to this router in which the server resides

I hope I am making sense in explaining this...

The static routes are indeed ugly, but due to some organization policies between us and the customer, a dynamic protocol can't be used in this case.

Paolo Bevilacqua Mon, 07/14/2008 - 15:04

Hi, you explained the issue very well.

The config command I gave you, does what you're asking for. You pick a public address and assign to an internal one, only for tcp port 80 in the example above. This has nothing to do with the NAT you guys are using to browse the Internet.

Now here's the gotcha that I forgot to mention before. Since the other site also has an independent internet access, you cannot let the reply packets to accesses from outside, to go thru that connection, because that would break the TCP.

So you need a special config called "PBR". that is policy based routing, on THEIR router, that is the one the other side of the frame relay. it goes like:

interface fastethernet x/y <-- the LAN IF facing server

ip policy route-map servers

access-list 111 permit tcp I.I.I.I 255.255.255.255 eq www any

!

route-map servers permit 10

match ip address 111

set ip next-hop 172.16.203.246

See also:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009481d.shtml

Sorry, there is no easier way than that. In other words, it's magic to tell that packets going to the internet in response to an access, should transit "YOUR" connection and not "THEIR".

If you can't quite grab the concept at first, don;t worry, there's people with 5 years experience that doesn't :)

Let us know and remember to rate useful posts!

Paolo Bevilacqua Mon, 07/14/2008 - 15:18

Got a second thought. Actually thre's is an alternative in case they really really do not want to use the PBC commands give above.

That would be making a superspecial NAT so the server sees all requests as coming from one of your LAN addresses, but it's much more complicated either conceptually and practically.

So I hope you will be happy with my first suggestion above.

sdoremus33 Mon, 07/14/2008 - 17:59

Paolo,

So with PBR the basic principle is to redirect the traffic sourced from 10.0.0./8 that say originally was set to flow through Interface ser0/0 because of route metric decisions say for simplicity RIP has one hop over serial0/0 and two hops over ser0/1.

But you have a route map specified for PBR

like this

route-map net-10 permit 10

match ip address 111

set interface serial0/1

traffic will now flow out serial0/1 interface

sdoremus33 Mon, 07/14/2008 - 18:01

match ip address 111

access list 111 permit ip 10.0.0.0 255.0.0.0

kenneth.rogers Mon, 07/14/2008 - 18:26

Excellent information.....it will be awhile before we can test this, but looking over some documents PBR should accomplish what we are trying to do. I will advise the discussion when we see what happens

Paolo Bevilacqua Tue, 07/15/2008 - 04:05

Hi,

If you will go testing that, remember that depending from were they also access the server I.I.I.I, ACL 111 may need further tuning.

Again, the idea is that only traffic going to the internet as replies to access, will take the special path.

Thanks for the appreciation and good luck!

Actions

This Discussion