1

I am currently working on a project for a SP and one of their requests has me stumped.

Background : enter image description here

The customer wants to move to a vendor's WAN solution and for the underlay , we are using DMVPN. The end points of the DMVPN tunnel are the CPEs. Customer router, unfortunately are mostly EOS and don't support DMVPN phase 3. For services, the customer need

  1. Internet connection
  2. LAN access between central site and branches

Problem

Due to limited number of Public IPs (2x/30), we have to use Dynamic NAT. Meeting requirement 2 is proving to be challenge. The packet flow I have understood is as such :

  • DC's client(say 10.1.1.1/32) tries to reach Branch's client ( say 10.20.1.1)

  • The packet follows a default route to Customer router WHERE it is NATTed to a public IP. The outside global entry is set to 10.20.1.1 and inside global and local are :port and 10.1.1.1:port

  • The packet is routed to 10.20.1.1 over the DMVPN tunnel ( routing between the CPEs is established).

  • 10.20.1.1 replies to with it's own address 10.20.1.1
  • 10.20.1.1 is NATted at Branch customer router to the connected public IP
  • This packet reaches the DC CPE over the tunnel which tries to perform a lookup in the NAT table but doesn't find any match outside global to inside local entry ( remember the source of the reply has been natted in step 5)

What has been tried

  • I am thinking of a solution where the NAT is done on the CPE, and we separate traffic using VRFs. CPE-PE is in a VRF INET, which is used as an underlay for DMVPN. EIGRP over DMVPN allows the Customer to access the LAN from the global RIB. A default route to the INET vrf and some leaking between INET and global allows access to Internet. The challenge here is that the outside interface would be in a VRF and this is not a typical case of VRF AWARE NAT ( where the source is in a VRF) . I tried running this on EVE, and couldn't get it to work.

  • I have also heard about Double NAT but can't include it into solving my problem

Any help is very much appreciated.

Improve this question
6
  • 1
    I think you may be making this way more complicated than should be, or maybe I simply don't understand why you need NAT for the site-to-site traffic? Why not simply route the rfc1918 subnets over the DMVPN ?
    – hertitu
    Commented Aug 14, 2017 at 13:20
  • Every branch site needs their own internet connection, which means the traffic will have to go over the public IPs. The two public pools between the customer and CPE router is a design constraint, enforced by the SP.
    – surya
    Commented Aug 14, 2017 at 16:52
  • 1
    So you NAT the internet traffic but not the site-site traffic?
    – hertitu
    Commented Aug 14, 2017 at 18:27
  • Since we have public ip between customer and CPE and the customer is to do the natting, I don't think we can choose not to nat for site to site.
    – surya
    Commented Aug 15, 2017 at 4:10
  • 1
    Well you wrote "I am thinking of a solution where the NAT is done on the CPE" so I assumed this would be an option. But even if you do the NAT on the customer router, he can choose to only NAT the internet traffic and not the site2site traffic?
    – hertitu
    Commented Aug 16, 2017 at 20:44

1 Answer 1

Reset to default
1

I believe to have grasped this from your problem description:

  • new SP delivers a WAN service which happens to have an internet exit "somewhere upstream".
  • CPE-CE link has to be a publicIPv4 /30, as given from new SP
  • to allow to reach the public Internet (via the SPs new WAN), SP mandates that the CE does SourceNAT/Overload, using the said /30 space.
  • the CE router therefore needs to have a default route pointing towards the new SP's CPE.
  • You still need to run an overlay to allow for connectivit to the Datacenter at your site.

Then this should work, I think:

  • Make sure that the overlay hub is reachable from all the spoke sites; this might require that you connect your datacenter to the same SP's WAN service, as if it were the (n+1)th site of that WAN. Else, you might have to connect the overlay's hub to the public internet.
  • On the CE, have a static default route point through the SP facing interface
  • Let the CE's LAN interface be "nat inside", let the SP facing interface be "nat outside".
  • With the NAT overload statement, use an ACL that denies RFC1918 destinations (or the RFC1918 "supernet" that covers the overlay network, other sites and DC included), and that has an explict "permit any" at the end.
  • Make sure that the tunnel interface is not "nat outside", and that it explicitely uses the SP facing interface as "tunnel source".
  • Make sure that the routes pointing through the VTI tunnel (probably learned via dynamic routing protocol) match the IP space which is excluded from NAT in the ACL.
  • When running a dynamic routing protocol across the tunnel (which I assume you do), do not advertise a default route to the CE routers.

If you are comfortable with advanced NAT setups (Global-to-VRF and the like) , then consider a setup like this:

  • put the SP facing interface into a VRF "INET"
  • keep a default route in VRF "INET" through the SP.
  • keep a default route in Global Routing Table (GRT) through VRF "INET"
  • keep the VTI Tunnel Interface and LAN Interface in the CE's GRT
  • use the "tunnel vrf INET" command under the tunnel interface.
  • make sure that the tunnel source (given by IP or interface name) actually is part of VRF "INET".
  • do the NAT magic (you'll probably still have to use the Source ACL) from GRT to VRF "INET"
Improve this answer
2
  • Your way works Marc. Fortunately for me, I was able to convince the customer not to NAT their LAN to LAN traffic, so I have now denied the LAN destinations in the source NAT. LAN to LAN follows the DMVPN tunnel and everything else gets natted for Internet
    – surya
    Commented Aug 18, 2017 at 2:16
  • Thanks for responding, I'm glad if it helped. There's one thing to be aware of, which the customer's CISO might want to hear about this --- or may be not ;-) When the DMVPN is down, all traffic from the spoke will follow the default route into the SP's WAN unNATted. This might leak some information about the IP address ranges and services available via the DMVPM overlay (i.e.: the SP will "see" the client's TCP SYNs, probably also DNS lookups and similar traffic). A handful of (floating) static routes pointing into the DMVPN tunnel or the null Interface might help to prevent this.
    – Marc 'netztier' Luethi
    Commented Aug 18, 2017 at 6:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.