Allow generic traffic from outside / vpn0

[mdewald]

Dear Community,

Currently we have a setup with 2 (two) C8500-12X4QC Routers. Those are located in our Datacenter where we also host some services to the public internet (services like mail, web and alike).

Is it possible to configure those routers to forward traffic destined to hosts with IPs from our /22 Ripe-assigned subnet in a service VPN? I know that there are some ways to steer the traffic but it seems that those are limited to SD-WAN Overlay traffic from one site/branch to another only, but not in a way to allow generic traffic 'from outside' on vpn0 and forward them to an specific service vpn.

I would really appreciate some input in regards of this matter, maybe someone already did something similiar already?

Kind regards,
M

[Kanan Huseynli · Accepted solution]

Hi,

from 20.9/17.9 port forwarding with DIA is supported. You can use either CLI template or feature template (VPN0 interface template where NAT is enabled).

From 20.11/17.11 you have an option to do port forwarding even using loopback interface (CLI-template only). Below describes configuration from NAT config guide:

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/nat/nat-book-xe-sdwan/configure-nat.html#port-forwarding-nat-dia

Also, you can check some my tests from another discussion:

https://community.cisco.com/t5/sd-wan-and-cloud-networking/support-for-port-forwarding-with-nat-dia-from-20-9-1/m-p/4808929

I don't know your current routing setup, but don't forget that NAT public IP should be reachable and advertised in routing somehow.

[mdewald]

Hi there!

Thank you very much for your answer.
I'll re-evaluate the links about NAT you mentioned.

In terms of my routing setup I currently peer directly with our ISP via eBGP. So I announce the respective prefixes already and I am able to ping the router from WAN point of view at the IP on vpn0 physical interface / NAT outside interface.

To clear this up; So there is no other possibility than port-forwarding via NAT (DIA) to forward traffic? Because until now our servers which provide previously mentioned services have the public IPs directly assigned to them.

Regards,
M

[Kanan Huseynli]

In networking there is two options to reach nodes externally (from internet):

either directly assigning public IP to nodes (server) or doing NAT from private to public (here you have an option 1:1 static nat or port forwarding (from he same or different port, depending on the case)).

Better to do only port based forwarding which "opens" your system - device to internet only one from port, not the entire IP.

[mdewald]

---

@Kanan Huseynli wrote:

Better to do only port based forwarding which "opens" your system - device to internet only one from port, not the entire IP.

---

This is correct, absolutely. For our background though, not practical.

---

@Kanan Huseynli wrote:

In networking there is two options to reach nodes externally (from internet):

either directly assigning public IP to nodes (server) or doing NAT from private to public (here you have an option 1:1 static nat or port forwarding (from he same or different port, depending on the case)).

---

That would be the most easiest approach with an existing infrastructure. I understand that the kind of role of this device in an SDN isn't exactly that something I'm trying to do, however, would be a desirable feature in my humble opinion. At least some more control in terms of external traffic in and out over the transport interface straight to the vrf's/service-vpn's.

Concerning my initial posting I accepted your answer linking to the other thread (and NAT doc), gave me quite some insight, and also my other theories we're negated there too. Therefore 'solved'.

Best regards,
M

[Kanan Huseynli]

Glad that I helped.

In general, why do you think that NAT does not fit to your case?

[mdewald]

I'm not saying that it wouldn't fit. This adds in my opinion unecessary config overhead.
It's just not very practical to migrate our existing infrastructure where the hosts have the IPs directly assigned to them.
The relative inflexible NAT of IOS XE devices is unfortunately not very helpful to make existing hosts available to the public.

[Kanan Huseynli]

I just didn't catch the point about "inflexibility of IOS XE". You either have public IP on host directly without NAT or private IP with NAT.

This should be the same in any vendor technology and NAT/ port forwarding is vendor agnostic approach to serve server to internet, do you know alternative implementation?

[mdewald]

I'm refering here one post from your aforementioned thread to clear up the confusion with inflexibility of IOS XE NAT.

https://community.cisco.com/t5/sd-wan-and-cloud-networking/support-for-port-forwarding-with-nat-dia-from-20-9-1/m-p/4809452/highlight/true#M5665

In terms of our 200+ VMs and other devices which have to be 'directly reachable' from the WAN, NAT does not scale very well here in regard of replacing previous routers which are controlling and forwarding traffic on an ACL basis where I can controll whole prefixes and where to 'next-hop' them.

Plain and simple; take traffic destined for prefix X to Next-Hop Y. In any scenario I've tested this with ACL, PBR, Extended PBR and Route Leaking but with no luck. NAT is seemingly the only contact point between 'outer world/WAN' and the available networks living inside of the service VPN(s).

IOS XR (service provider level) seems to be the better fit instead of IOS XE (Enterprise level).

Regards,
M

[Kanan Huseynli]

Assuming no firewall between service and transport sides, route-leaking with access-list based filtering should work.

Could you draw the topology example, please? I'll check in lab

[mdewald]

Hey.
Sorry for the delay.
Here as requested;

Regards,
M

[Kanan Huseynli · Accepted solution]

So, as I see you have BGP both in Service side and Transport side and most probably you advertise public range for VMs to internet providers.

I have checked route leaking between service-side and global (transport side) it worked normal. First you need

You should replicate and redistribute these routes. It works over routing table (so on best ones). Below is an example from my lab:

router bgp 65001
bgp router-id 1.1.1.1
bgp log-neighbor-changes
neighbor 172.20.2.254 remote-as 65002
neighbor 172.20.2.254 description ISP1
!
address-family ipv4
redistribute vrf 1 bgp 65001 > redistribute replicated routes
neighbor 172.20.2.254 activate
neighbor 172.20.2.254 send-community both
exit-address-family
!
address-family ipv4 vrf 1
bgp router-id 1.1.1.1
redistribute vrf global bgp 65001 > redistribute replicated routes
neighbor 10.1.1.253 remote-as 64999 > service side BGP peer
neighbor 10.1.1.253 activate
neighbor 10.1.1.253 send-community both
exit-address-family

vrf definition 1
address-family ipv4
route-replicate from vrf global unicast bgp 65001 > replicate from bgp global to vrf 1 table

global-address-family ipv4
route-replicate from vrf 1 unicast bgp 65001 > replicate from bgp vrf to global table

What I've seen, default route is not redistributed in BGP (I remember it should be BGP issue). You need another options (like neighbor a.b.c.d default-originate in BGP).

This approach works both in case when WAN transport interface is with NAT or without NAT.

Scenario w/o NAT is simple, just routing happens.

Scenario w/ NAT is a bit complicated, since DIA NAT statement has NAT statement with access-list, you need somehow bypass this NAT. Below is that NAT statement (action pool, interface, loopback does not matter, focus on source list)

ip nat inside source list nat-dia-vpn-hop-access-list interface GigabitEthernet1 overload

This access-list matches any traffic routed to transport interface, so your service-side traffic will be NAT-ed to this IP address. Unfortunately, access-list is hidden and there is no way to bypass it by modifying this acl and nat statement.
But you can do 1:1 static NAT where original and mapped IP are the same. It will be like bypassing acl, because static is preferred over dynamic NAT statements. These static entries should be in VRF as below (100.100.100.1 is internal public IP - like your VM from lab)

ip nat inside source static 100.100.100.1 100.100.100.1 vrf 1 egress-interface GigabitEthernet1

[mdewald]

Hello there. Please pardon the long delay.
I've spent the last week to check any other aspect of my setup (beside the routers) to make sure not wasting your time.

In fact, your example made it really clear to me how to handle the redistribution and replication of those routes inside of the routers. After all; This seems to work now!

Thank you very much for the time you spent helping me out! I deeply appreciate that.

Best regards,
M