I have an ASA that uses a static NAT ex:
static (inside,outside) 192.0.2.178 10.192.100.178 netmask 255.255.255.255
I am running OSPF between the ASA and a border router. I have a static route on the border router pointing traffic for 192.0.2.178/32 to the ASA. I would like to eliminate the static route on the border, and simply announce the host-specific route from the ASA using the OSPF process.
I have tried a static route on the ASA that points to its outside interface:
route outside 192.0.2.1 255.255.255.255 10.128.253.1 1
and I have "redistribute static subnets" in the ospf process.
The ospf Link state appears in the border router, and the traffic is forwarded to the ASA, but it doesn't make it through.
can anyone recommend a way to accomplish this? I would like to do this similarly to announcing a null0 route from a router, but the ASA doesn't support the interface syntax for a destination in a static route statement.
ideas anyone? Thanks!
I don't think the ASA will allow the inside to form a neighbor thru the outside - passing thru NAT.
Have you tired forming a neighbor with the outside interface on the ASA with your ABR?
Sorry, I may not have been clear with the first post. Yes, a neighbor relationship already exists, and there are network statements in the OSPF process on the ASA that are received by the border router, and routing is fine. But those are for private, internal IP subnets that are announced from the ASA. (ex: 10.0.0.0/16 as a summary route). That works fine and has been for some time.
The issue is, that I now have a static nat configured on the firewall, and the outside address is a public IP (not used in my example.... but it is a public IP) and I have a static route for that public IP configured on the firewall pointing to the outside interface of the firewall, so that the OSPF process on the firewall will announce the route to the border router... and it does, no problem. The link state appears in the border router, and the traffic is sent to the ASA.... but it never gets through the NAT.
When I remove the static route on the firewall, and put a static route on the border router pointing to the firewall, everything works fine.
The issue is, I don't want to have to touch the border router to put a static route on there pointing the traffic to the firewall for the public IP used by the NAT on the firewall.
I want to be able to simply announce (from the firewall) the public IP for that NAT statement so that the border router learns the route directly from the fireall. Make sense as I described it? want to be sure I am stating this clearly....
OK - I think I understand the issue, but there is something I don't understand.
Is the outside interface on the firewall a differenet IP/subnet from the one you want to advertise to the border router, from the ASA?
Also - if the public IP that you want to route to from the border router will never change (as I presume you own it) and the border router will always be 1 hop away - what is the issue with having a static route?
Yes, the outside IP of the ASA is 10.172.253.x and the public IP being used in the static NAT statement, lets say is 192.0.2.178/32.
Yes, we do own the public space and yes, the border router will always be one hop away, and a static route on the border router works just fine, no doubt about it.
The issue is that we will likely be adding and removing these NATS on a semi-regular basis (ad-hoc development environment for partners to access a resource we build specifically for them) and I want to be able to touch only one device (the firewall) to do the three things that need to occur: 1) setup a NAT, 2) setup the access-list permissions and object-groups for the partner and 3) get the traffic routed from the border router (where the public subnet is announced via BGP already) to the ASA.
The only piece left on the border router is having to put the static route in for that specific host (these are all host specific routes, because the hosts themselves can reside behind at least 2 different firewalls and possibly more moving forward.
So the purpose really is consolidation of configuration requirements to the firewall itself. Make sense?
Makes sense! mmmmmm interesting issue....
Just one more question - are you natting to an IP address from the same IP subnet range as the outside interface??
Not sure I follow the question.... but I think your asking if the IP address specified as the "inside" component of the ASA's NAT statement is in the same subnet as the ASA's "outside" interface. No, the inside IP is 10.192.100.178 as defined in the NAT. The ASA's inside interface is 10.192.100.1. Its outside interface is 10.128.253.14
If the IP address is public, and you are redistributing from the firewall using a static route in a route-map or something.....why dont you just exempt it from NAT....it's routable on the internat anyway right? So don't nat it thru the firewall?
no.. the NAT statement is there because the host is addressed privately behind the firewall. The NAT is necessary. The issue remains... how to you "announce" an IP route upstream for an IP that is assigned as the "outside" element of a static NAT.
If I understand the problem correctly, you could apply secondary ip address to you border router from the subnet the public ip addresses (used in statics) are from. The router will see them as directly connected and simply arp for them and the asa will reply.
OK - so let me get this straight, using exmples:-
ASA outside IP 172.16.1.1
ASA inside IP 192.168.1.1
Inside Server 192.168.1.50
Public NAT IP 10.1.1.1
You want to know how to advertise the 10.1.1.1 from the ASA to the border router. Then NAT the traffic destined for 10.1.1.1 on the ASA which has an outside IP address of 172.16.1.1 and sucessfuly NAT it to 192.168.1.50 when the border router has a desination of 10.1.1.1 via 172.16.1.1 - is this about it?
1) Create a 1:1 NAT ~ static (inside,outside) 10.1.1.1 192.168.1.50 netmask 255.255.255.255
(Tell the ASA anything for 10.1.1.1 should be NATT'd to 192.168.1.50)
2) Create a static route for the public NAT to route inside ASA interface ~ route inside 10.1.1.1 255.255.255.255 192.168.1.1
(Tell the ASA that 10.1.1.1 is reachable out of the inside interface - as the inside interface is valid, the route will be put into the route table)
3) Redistirbute the static routes into ospf ~ redistribute static metric-type 2 metric 100 subnets
(Tell the ASA to redistribute static routes, I would use an E2 OSPF route, as the metric does not change thru the OSPF domain, and use subnets just in case you just don't have hosts)
Your border router should recevie an Type 5 - External Type 2 LSA with the public IP. the ASA knows that 10.1.1.1 is in the inside and will know to NAT 10.1.1.1 to 192.168.1.50.
Thanks, you got the issue as you described it.
And, yes, understood on all points. That is precisely what I did the very first time to try to get it working. I didn't metric the subnets specifically in the redistributed statement, but that's a nice touch. I guess my concern is that.... it didn't work. At least not that I recall.
All of the structure with the exception of the specific static route was already in place of course, and the NAT'd resource was working, based on the fact that the static route was on the border router.
Then I removed the static from the border, installed a static on the ASA exactly as you indicated above.... but couldn't get the traffic through. (Again the OSPF process was working, the redistrib static was already in there, and the route appeared in the OSPF database on the border router...)
I will try it again though, perhaps I missed a step. Since you have basically arrived at the very same config I originally tried, it is worth another look. I may have flubbed something in the config.
Thanks for all the responses! Its been good to collaborate on this. I will post back one I try it. May have time tonight.
Sure no issues - I tested my own suggestion in a simple lab 2x2600 and a PIX515 running 8.0(3).
1x2600 was the ABR, and other router was acting as an inside host. The inside host running TCP small servers. The ABR received the E2 route - connected thru the firewall using the static redistributed NAT address with no issues. PING and TCP connection using TCP port 19 (TCP Small Services). I added a few public IP examples - and a route map, filtering selective IP's with a metric and a specific type 5 LSA - this is really important you must ensure there is no better route in your OSPF domain.
See the attached for the network topology and config example I used in the lab - it worked 100%.
But why do need to this? Is it because you have two different public ip ranges for your internet circuit? If that's the case, you would just need to assign the range you are using for your public address in the statics as the secondary ip address range to inside interface of your border router (connected to the ASA)
IIFR Pix OS < 7.2(2) did this by default. With a config like:
ip address 220.127.116.11 255.255.255.252
ip address 192.168.1.1 255.255.255.0
static (inside,outside) 192.168.100.100 18.104.22.168 netmask 255.255.255.255
OSPF used to announce 22.214.171.124/30 out the outside interface.
I used to use this functionality but when I upgraded to 7.2(3), it stopped working.
I'm still not sure if this was a feature of a "feature"
Unfortunately, I have very limited experience with the PIX/ASA product line, so I'm not sure how applicable this will be. However, with ISRs it's as simple as creating a static NAT entry, a static route towards the actual host, and redistribution into your routing protocol. Obviously there is a lot of personalization that can be done at each point depending on the design, but those are really the basic steps.
ip address 126.96.36.199 255.255.255.0
ip nat enable
ip address 10.10.10.1 255.255.255.0
ip nat enable
ip nat source static 10.10.10.5 100.100.100.5
ip route 100.100.100.5 255.255.255.255 10.10.10.5
Redistribute static routes into routing protocol, modify route-filters, apply seed metrics, firewall policies, etc.
I know this is basic but I hope you find it helpful.