Archive for the ‘nat’ tag
ASA and Proxy ARP
Wow. A new entry. Everyone sit down before you pass out.
I’ve got a real-world example for you today. We have an ASA 5540 installed at a business unit with interfaces in multiple networks, including one containing the production servers and another containing the accounting servers. The production network sits on a 7600 that’s not ours, so, to avoid IP conflicts, we are statically NATting connections into that network. The 7600 has with many, many VLANs, and, since the firewall production servers are on different VLANs, there’s an interface VLAN between us. Sounds pretty straightforward, but it just wasn’t working when we try to connect between the interfaces.
When we tried to connect from the accounting servers to the production gear, the firewall saw the SYN, built the outbound connection, sent the packet on, and waited. Nothing back. SYN timeout. The vendor on the production side checked the routing. Fine. Checked the ACLs. None installed. When the (other) vendor ran TCPDump on the production servers, they saw the SYN landing and the SYN-ACK leaving, but it never got to the ASA. We even looked at the inline IDS and still didn’t see the SYS-ACK hitting the firewall. It was simply not getting passed on.
I got tired of walking people through stuff over the phone, so I drove up there to see what I could find. When I checked the ARP table on the 7600, I noticed that the statically NATted IP we were serving was conveniently incomplete. For those who don’t know, that means that the 7600 was ARPing for the address, but nothing was answering for it. Obviously, our ASA should be answering, right? To make the situation a little more dire, I did a debug arp (or something close) on the firewall and generated an ARP request; the firewall saw the request but just ignored it. Ugh!
If you couldn’t tell by the title, it turns out that the solution was to enable proxy ARP. It’s off by default for good reason, but here’s how to enable it.
no sysopt noproxyarp PRODUCTIONINTERFACE
Enabling proxy ARP, however, could be a security issue. Any time you use the word “proxy”, there is a potential to spoof addresses, and, in this case, an attacker could (potentially) use the firewall to discover hosts that are on the other side of it. That wouldn’t be good.
A more-secure solution is to use static ARP entries. In our case, we added a static ARP entry on the 7600 that points our NATted IP to the MAC address of the firewall. Now, when you ping the IP, the 7600 doesn’t ARP; it already has the MAC in the ARP table, so it just sends the packet on. Since we only have one static translation in this case, it’s no big deal, but, if we had a whole class-C of addresses to NAT, there would be a management problem.
A part of me wants to do the simple thing and enable proxy ARP, but the vast majority of article, blogs, forums, lists, etc., that I’ve ready say to turn it off for security and efficiency purposes. The more I think about it, though, the more Iwonder why proxy ARP needs to be enabled to make staic NATs work. I looked back at an old PIX running 6.x, and proxy ARP is on by default. The same holds true for an FWSM running 2.x. I’m going to have to ask Cisco what’s up with that.
Send any misconfigured subnet masks questions my way.
Port Forwarding on the ASA/FWSM/PIX
Here’s a simple one since I haven’t updated in a while. I have my ASA 5505 at home and want to forward TCP/80 traffic to my public IP to my webserver at 10.10.10.10. There are two steps here — forward the port and open the ACL.
To forward the port, I would use the static directive, but there are two ways to do that. I can either set up a one-to-one NAT or a port redirection. In the one-to-one NAT, you have a outside address that’s mapped directly to an inside address, and any traffic to that IP is passed to the inside host (if it passes ACLS, of course). One of the limitation, though, of using this setup is that you can’t use that IP as your PAT address, and, since I only have one IP, no other inside hosts would have a outside address to which to be NATted. The other method — port redirection — is a much better solution. In this setup, I actually forward a protocol/port on a outside address to a protocol/port on an inside address. Since there are other ports available on that outside address, the address is still available for other hosts to use as a NAT address.
In an enterprise, I would probably use an address out of my pool for the port forwarding, but, since I only have one address at home, I’ve got another decision to make. I can configure the static statement with an IP address or I can use the reserved word interface to indicate the IP that is on an interface. This is a great feature, actually, since my outside IP could potentially change without notice. I’m going to use that feature, too.
static (inside,outside) tcp interface 80 10.10.10.10 80
This is pretty simple, but I’ll explain. The ASA will take any request that comes in on TCP/80 (HTTP) on its outside interface’s IP and forward it to TCP/80 of 10.10.10.10. If my webserver ran on TCP/81 on my box, I could just change the last 80 to 81 to make it work.
The port is redirecting, but I still need to open the ACL. When that’s done, everything should work as expected.
Star-crossed Lovers: HSRP/VRRP and NAT
I was doing an HSRP lab the other day, and a project from the past popped into my head. A customer had a host on a network that was separated from the rest of the network by a 1700 with a couple of FEs. They wanted that host to be NATted to a local address so that they didn’t have to do any routing, which makes sense, I guess. This is just your standard 1-to-1 NAT, so we plunked down a quick config.
The setup had two networks with 192.168.0.0/24 on the customer’s local network and 192.168.1.0/24 on the “DMZ” (Yes, I know it’s not really a DMZ). We want to NAT 192.168.1.100 to 192.168.0.100.
interface FastEthernet0/0
ip address 192.168.0.10 255.255.255.0
ip nat inside
!
interface FastEthernet0/1
ip address 192.168.1.10 255.255.255.0
ip nat outside
!
ip nat inside source static 192.168.1.100 192.168.0.100
This works great, but then the customer asked for some redundancy. He wanted a second router inline that could take over in case of failure on the original. “Piece of cake,” I thought and went about setting up the HSRP stuff on both the original and new second routers.
interface FastEthernet0/0
standby ip 192.168.0.1
standby preempt
standby name MYHSRP
But what about that NAT thing? If the primary router goes down, the NAT goes down with it. If I configure the secondary router for the NAT, we get an IP conflict. I looked around for a while and found a feature introduced in IOS version 12.2(4) that allows a NAT to follow an HSRP or VRRP active member. If a router is the active member of an HSRP or VRRP cluster, the NAT is with that box; if it fails over, the standby IP and the NAT move. Isn’t that cool? The only caveat is that it keys off the name/description of the HSRP/VRRP cluster instead of the ID, so you have to have that configured as we do above.
ip nat inside source static 192.168.1.100 192.168.0.100 redundancy MYHSRP
Let’s test to be sure it works. On the active member (a router called NAT0), we can look at the ARP table and see that this router is speaking for the NAT address of 192.168.0.100 as well as the HSRP IP of 192.168.0.1. The secondary member (NAT1) only has ARP entries for its interface IPs. Looks good so far.
NAT0#show standby brief
Interface Grp Prio P State Active Standby Virtual IP
Fa0/0 0 100 P Active local 192.168.0.11 192.168.0.1
NAT0#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.0.100 - c800.12bc.0000 ARPA FastEthernet0/0
Internet 192.168.0.10 - c800.12bc.0000 ARPA FastEthernet0/0
Internet 192.168.1.10 - c800.12bc.0001 ARPA FastEthernet0/1
Internet 192.168.0.1 - 0000.0c07.ac00 ARPA FastEthernet0/0
...
NAT1#show standby brief
Interface Grp Prio P State Active Standby Virtual IP
Fa0/0 0 100 P Standby 192.168.0.10 local 192.168.0.1
NAT1#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.11 - c801.12bc.0001 ARPA FastEthernet0/1
Internet 192.168.0.11 - c801.12bc.0000 ARPA FastEthernet0/0
When I shut down F0/0 on NAT0, the HSRP and NAT both roll over to NAT1.
AT0(config)#int f0/0
NAT0(config-if)#shut
*Mar 1 00:30:25.248: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 0 state Active -> Init
*Mar 1 00:30:27.263: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar 1 00:30:28.265: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
NAT0#
NAT0#sh stand b
Interface Grp Prio P State Active Standby Virtual IP
Fa0/0 0 100 P Init unknown unknown 192.168.0.1
NAT0#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.10 - c800.12bc.0001 ARPA FastEthernet0/1
...
NAT1#sh stand b
Interface Grp Prio P State Active Standby Virtual IP
Fa0/0 0 100 P Active local unknown 192.168.0.1
NAT1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.0.100 - c801.12bc.0000 ARPA FastEthernet0/0
Internet 192.168.1.11 - c801.12bc.0001 ARPA FastEthernet0/1
Internet 192.168.0.11 - c801.12bc.0000 ARPA FastEthernet0/0
Internet 192.168.0.1 - 0000.0c07.ac00 ARPA FastEthernet0/0
Now we have redundancy and NAT on the same cluster. Sweet. I also did the same lab for VRRP, but I’ll spare you the innards. When you configure VRRP, you can give it a description, which is the same as the name in HSRP. You use that string as the redundancy name to have a NAT move with VRRP. Yes, you can do both an HSRP- and VRRP-based NAT at the same time.
*I labbed this out on a Dyanmips/Dynagen instance of two 2651XM routers running 12.4(19) Advanced Enterprise. Like all the configs here, your mileage may vary if you have different versions or feature sets on your routers.
Edit: I wanted to make a not on GLBP and NAT. Since all the nodes in a GLBP cluster actually route traffic and are routed to, you can’t use this type of NAT solution with it. I don’t know what the best practice would be, but I imagine it would involve running HSRP on a few routers as we talked about above.
NAT on a PIX/ASA
NATting sucks and can be confusing. I’m sure everyone agrees to that, but you have to use it at some times. In a PIX/ASA, it’s easy to configure a simple setup, but can be super-complicated in larger networks. In a simple lab, we have set up an ASA with inside and outside interfaces, with the inside as your internal and outside as the Internet.
The NAT setup here is easy.
nat (inside) 1 0.0.0.0 0.0.0.0
global (outside) 1 interface
This NATs everyone on the inside (0.0.0.0 with a mask of 0.0.0.0, or 0/0) to the IP of the outside interface (overload in the IOS world). The nat command says who gets NATted; the global command says what they get NATted to. Notice the number “1″ in both commands; this is the NAT group and allows you to have some flexibility in your NAT strategy. In essence, if you match a nat line with a “1″ in it, you’ll be matched to a “1″ on the global list.
What if you add a DMZ interface and don’t want to NAT when your inside network talks to it? That, my friend, is a little more complicated. We’ll assume your internal network is 10.0.0.0/24 and your DMZ is 192.168.0.0/24.
access-list NONAT permit ip 10.0.0.0 255.255.255.0 192.168.0.0 255.255.255.0
nat (inside) 0 access-list NONAT
nat (inside) 1 0.0.0.0 0.0.0.0
nat (dmz) 1 0.0.0.0 0.0.0.0global (outside) 1 interface
That was painful, but what did it do? That’s a very good question.
We have multiple nat lines on the inside, so the firewall starts at the top and works its way down (there are exceptions). The first nat line has a group of 0, which is very special. If you match group 0, you are not NATted at all, and your connection is passed as-is with no changes. In our second example, you match if the ACL matches, so, if you’re going from the inside network to the DMZ, you won’t be NATted. If your connection didn’t match this line (like you’re downloading porn from the Internet), the firewall goes to the next line, which says to NAT everyone to group 1 just as we did in the first example.
Another twist here is the “nat (dmz) 1 0.0.0.0 0.0.0.0″ line. This says that anything from the DMZ is NATted to group 1 just as the inside traffic is.
So, if the inside network connects to the DMZ, it doesn’t get NATted. If the inside goes to the Internet, it gets NATted to the outside IP of the firewall. If the DMZ connects to the Internet, it gets NATted to the outside IP as well, but what if the DMZ connects to the inside? That’s another story. :)