Passing Public IPs through multiple ASA's (Part 2) - Continued

[mst2irad4113]

This is the continuation of an issue posted on : https://supportforums.cisco.com/discussion/12463791/passing-public-ips-through-multiple-asas-part-1

[Jon Marshall]

Okay, well that suggests you do have connectivity between the two firewalls.

How are you testing this, are you just pinging 70.x.x.231 from an internet IP ?

Both firewalls are allowing all IP which includes ICMP and if they are allowing it in then they should by default be allowing it back out again.

Do you have a packet capture tool on your laptop by any chance ?

Jon

[mst2irad4113]

I am testing by using a laptop that is connected to a separate internet connection. Then I just ping 70.x.x.231 from it. Since all ports are open, I even tried to RDP to it. Neither laptop has a packet capture tool.

[Jon Marshall]

Okay, I have never used the capture command before but can you try this on ASA 5505 (1).

to setup the capture -

access-list cap extended permit ip any host 73.x.x.231
capture capin interface outside access-list cap

then try pinging from your client on the internet -

then stop the capture -

no capture capin

and display the capture -

show capture capin

Jon

[mst2irad4113]

The 5512 was assigned an old IP and will eventually get it's own new one, but it doesn't currently have one.

Holy.... I rebooted my laptop because it was giving me an error and now the ping works. Do you think that perhaps the ASA's need time to update their arp tables or something that would have delayed the change from working? Either way I can now ping from the outside to 70.x.x.231.

[Jon Marshall]

The ASAs shouldn't have needed to.

I'm glad to hear it's working because I couldn't see what was wrong with from the ASA side.

While you were doing all that I had a quick chat with a colleague on these forums about NAT and VPN and he said although not ideal it will work fine for all VPNs using NAT.

I'm a bit out of practice on those but i'll help as much as I can.

So assuming it is now working what do you want to do next ie. get general internet access working or assign a private IP to 5505 (2) and setup NAT on 5505 (1) and make sure we can ping it etc.

Up to you.

Jon

[mst2irad4113]

Now that we got this to work, does this mean we passed all the public IPs through the 5510 un-NAT'd?

If so, the next step we should take is to get a public IP NAT'd to the outside interface of the 5505 (2) - for VPN purposes.

The public IP I need to use for it is 70.x.x.236

Just to show that I am learning are the steps I need to take...

1. Make sure the outside interface of the 5505 (2) is on the same VLAN and subnet as the inside port it's connected to on the 5505 (1)
2. Create NAT rule on the 5505 (1)... 70.x.x.236 > 10.50.0.11 > Permit (both directions)
3. Create ACLs on the 5505 (1)... 70.x.x.236 > 10.50.0.11 > IP (eventually just VPN) > Permit (both directions)

Question: With us passing the public IPs through... does this mean that the 5505 (1) can not have it's own public IP?

[Jon Marshall]

Question: With us passing the public IPs through... does this mean that the 5505 (1) can not have it's own public IP?

Not sure what you mean.

ASA 5505 (1) is not passing any through to 5505 (2) because you translating to a private IP on 5505 (1).

And you are already using public IPs on the 5505 (1).

Your steps above are good but I can't say for sure how well your VPN setups will work.

The NAT rule is just a copy of what you have for 70.x.x.231 ie. by definition a static is both ways anyway.

Like I say I spoke to an experienced colleague on these forums but my question was rather general whereas Matt is being quite specific.

And it's been a while since I did it.

But yes do the above and then add "icmp permit any outside" on 5505 (2) temporarily and you should be able to ping through from your internet client again.

Jon

[mst2irad4113]

I ran the "nat (inside,outside) static 70.x.x.236" command under the network object of 10.50.0.11 on the 5505 (1) as well as the icmp command.

I am able to ping 70.x.x.236 with the outside laptop. And just to double check, I enabled SSH on the outside interface of the 5505 (2) and used Putty to log in publicly; which I did. I then turned off SSH on the outside interface.

This is GREAT PROGRESS!! I have four days to complete this project and I have a meeting with the network security team and my bosses on Monday to explain everything.

I assume that from here on out, I can just create network objects and then NAT rules on the 5505 (1) to point public IP's to wherever I want? (along with ACLs).

For clarification regarding my previous post. Is it still possible to assign a public IP to the outside interface of the 5505 (1)? Just in case down the road I want the ability to VPN into it.

If so, I would like to set that up next.

If not, then the next thing I need to do is grant internet access to the inside interface of the 5505 (1). Followed by assigning a public IP to the 5505 (3) - Which I believe I know how to do; and then allow internet access on the inside interface of the 5505 (3).

[Jon Marshall]

You can continue to create network objects with NAT for the public IPs yes and now you have it working the new ones should work as well.

Yes you could assign one of the 70.x.x.224 IPs to the outside interface of 5505 (1).

This should work fine as long as you do not need to pass any of the 70.x.x.224 IPs to the inside which you aren't at present.

If you did you may need host routes but like I say you aren't currently.

Bear in mind this also means you will need to readdress the inside interface of 5510 so you have to use one of your IPs for that.

If you did do that you no longer need the route on 5510 for those public IPs because it now has a directly connected interface.

In terms of general internet access through 5505 (1) I recommend you have a good read of that document I linked to in the other part of this post. The NAT on 8.3 or later depends on an ordering.

So for example we could have placed the static statements in section 1 but we put them in section 2 instead which is Cisco's and that documents recommendation. But you need to be careful that any dynamic NAT you do is now in either section 2 or section 3 so as not to override your static statements.

It is a little complicated so it really is worth reading the document to get an understanding of which NAT rules go where and the way the ASA orders them. It will help avoid issues later on.

Let me know if you need help with anything else and i'll be only too happy to help out.

Jon

[mst2irad4113]

I can't thank you enough. I still have four days to put this all together but I have my confidence back. Thank you.

Quick question. The way we have set it up now; does this mean the only static route needed on the 5510 is the one that exists for the 70.x.x.224/28 > 5505 (1)? Everything else can go away, right? The static routes for all of my networks (inside of the 5505) should all just need to be on the 5505 (1). I'm trying to clean up the 5510.

I will definitely read that link you provided regarding NATing.

[Jon Marshall]

No problem, glad your feeling more positive about it :-)

If all the internal IPs ie. the ones behind the inside interface of 5505 (1) are going to be translated to public IPs, and that includes inbound from the internet and general internet access from inside clients, then you don't need any routes on the 5510 for any of those subnets.

All you should need is the route for the public IP block.

Jon

[mattp0002]

I just read thru both these threads.  What a cluster.

mst2irad just calm down bro and remember that the ASA is merely a router that has a policy on it to selectively pass packets based on a ruleset.  Otherwise treat it as a router.  The asymm routing warning you received was probably just the resut of a misconfiguration.

Both of Jon and your suggestions will work great for inside-->out web surfing.  (1. double-Nat and 2. move the public ip subnet behind the 5510 and then nat as you please).  But yes you will have problems bringing up both ipsec tunnels (perhaps NAT-T or TLS tunnels can work if initiated from the inside of this lab) and inbound (externally initiated) VPN tunnels.

Just pick a plan and start at the 5510 and confirm your connectivity as your build it out, hop by hop and get further and further in.  Open up your ruleset to allow anything from the internal zone to the external zone for now on each firewall, and lock it down later.

You can definitely also subnet your block further, and assign the cut subnet even deeper behind the first 5505, but you'll waste some more IP addresses that way and it's not very big to begin with so I wouldn't unless you need to.

Good luck

[Jon Marshall]

Matt

But yes you will have problems bringing up both ipsec tunnels (perhaps NAT-T or TLS tunnels can work if initiated from the inside of this lab) and inbound (externally initiated) VPN tunnels.

Like I say I'm a bit out of practice on these.

I did chat to another guy on these forums about this because I always used to have issues with NAT and VPNs.

Are you saying you can't initiate VPN to a public IP which is then translated to a private IP which is on another firewall.

Be good to know now before continuing :-)

Jon

[mattp0002]

Jon,

I think there's so many types of tunnels we call "VPN" now it gets confusing.

We have the "old fashioned" ipsec route-map deal on Cisco routers applied to "interesting traffic" as they say.

We have the VTI virtual tunnel interface ipsec config on Cisco routers.

These old fashioned ipsec tunnels negotiate on udp 4500 isakmp and then transfer traffic using ip protocol 50 or 51 depending on if you are running AH or ESP mode. (you probably want to do ESP).

We also have NAT-T mode of ipsec where the data payload is transferred across a NAT using a udp 4500 stream.

We have a SSL vpn

We have TLS vpn.

(I think these are called "anyconnect" VPN on the ASA)

Don't forget we still have PPTP VPN tunnels using TCP 1723, but I wouldn't use that if I were you.

So at this point will any of those work from the outside-->in in this lab?  Perhaps some will with a 1-to-1 static nat config, but probably not with a pat config (overload).  Some won't work at all I don't think (traditional isakmp ipsec) unless maybe you loosen up the protocol negotiation (lower the security checks).

In other words, I'm not sure.

[Jon Marshall]

Just wanted to check.

The 5512 connecting to the 5510, that wouldn't be using any of the public IPs would it ?

Jon